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Specialty  Engineering  Discipline  (SED)  Framework  Overview 

The  SED  framework  includes  the  essential  activities,  tasks,  and  products  that  shape  the  body  of  knowledge  for 
each  SED.  A  SED  framework  is  essential  for  each  engineering  discipline  to  effectively  scope,  plan,  staff,  and 
execute  engineering  activities  and  to  ensure  that  each  discipline's  contribution  is  timely,  adequate,  consistent, 
and  compliant  to  support  development,  deployment,  and  sustainment  of  the  SMC  space  portfolio  of  programs 
and  systems.  The  SED  framework  captures  the  SEDs  identified  in  Table  1  below. 

Table  1  List  of  SMC  SEDs 


SMC  Specialty  Engineering  Disciplines 

Systems  Engineering 

Test  &  Evafuation 

Software  Engineering 

Integrated  Logistics  Support 

Design  Engineering 

Manufacturing  and  Producibility 

Quality  Assurance  ‘ 

Reliability  and  Maintainability 

Spectrum  Management 

Concept  Development  : 

Architecture  Engineering 

System  Safety  Engineering 

Acquisition  Systems  Protection  &  International  Program  Security 

Survivability 

Human  Systems  Integration 

Mass  Properties 

EMI/EMC 

Parts,  Materials  &  Processes 

Information  Assurance 

Netcentnc  Engineering 

Environmental  Engineering 

Prognostics,  Diagnostics  Health  Management 

Standard  SED  Framework  Characteristics  and  Parts 

The  SMC  SED  framework  is  designed  to  characteristically  capture  the  following  attributes: 

1.  Provide  SED  contributions  to  all  major  SMC  acquisition  activities  while  accounting  for  acquisition 
phase  dependencies. 

2.  Integrate  with  the  overarching  Systems  Engine ering  activities  and  adjunct  Specialty  Engineering 
activities. 

3 .  Integrate  with  the  program  and  project  management  activities. 

4 .  C omply  with  techni  cal  niand  a  tes ,  re  gulations ,  and  o  bj  ec  tiv es . 

5.  Provide  a  high  degree  of  usability  to  leverage  for  Program  Office  detailed  Specialty  Engineering 
planning,  process  development  and  SEDs  execution. 
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6.  Provide  a  low  risk  and  cost  effective  path  toward  mission  success. 

To  capture  these  attributes,  the  SEDs  framework  is  made  up  of  die  following  parts: 

1 .  Applic  a  bie  go vemanc  e .  stand  ai  d  s ,  and  guid  anc  e . 

2.  Specialty  Engineers'  contributions  within  the  acquisition  hie  cycle  framework  for  SMC  Specialty 
Engineering. 

3.  Specialty  Engineers1  contributions  within  the  engineering  life  cycle  framework  for  SMC  Specialty 
Engineering. 

4 .  Sp  eeial  ty  Engineer s 1  c  on  tribu  tions  to  program  and  pr oj  e  c  t  niana  geme  nt . 

How  to  use  this  SED  Framework 

This  SED  framework  describes  necessaiy  tasks  and  products,  the  policy  from  which  they  are  derived,  then 
relationsliip  to  the  engineering,  acquisition,  and  program  management  frameworks,  and  the  engineering  details 
one  should  consider  in  working  towards  effective  and  efficient  integrated  engineering.  Hie  importance  of  this 
document  is  not  only  to  the  government,  but  also  to  the  providers  (contractors). 

Program  and  Project  Managers 

If  you  are  a  program  or  project  manager,  you  should  be  familial’  with  all  system  and  specialty  engineering 
major  events,  activities  and  products  that  apply  to  your  program  or  project  including  those  that  fall  within  the 
purview  of  the  engineering  directorate.  With  the  assistance  of  the  Cliief  Engineer  or  Lead  Systems  Engineer, 
use  tills  SED  fr  amework  to: 

1 .  Determine  which  SEDs  apply  to  your  program. 

2.  Assist  the  systems  engineering  organization  to  scope  the  engineering  work  to  be  accomplished, 
determine  the  resources  required,  provide  die  detailed  and  integrated  planning  and  scheduling,  staff 
and  execute  all  activities  in  an  integrated  faslion. 

3.  Ensure  the  detailed  planning  is  sufficiently  integrated  into  the  integrated  planning  and  scheduling. 

4.  Ensure  die  engine ering  control  activities  are  coupled  to  the  progr  am  monitoring  and  control  activities. 

5.  Ensure  the  engineering  contributions  are  sufficiently  provided  to  support  the  acquisition  activities  and 
products. 

Chief  Engineer 

1.  Read  tlnough  tliis  entire  SED  framework  and  support  the  Program  or  Project  Manager  to  determine 
which  SEDs  apply  to  your  progr  am. 

2.  Ensure  the  program  organization  is  stoic  tured  to  execute  the  applicable  engineering  activities 
described  in  this  SED  framework. 

3.  Determine  and  ensure  development  and  management  of  teclmical  and  engineering  Operating 
Instructions  (10 s  =  processes)  to  perform  the  engineering  tasks  described  herein  and  other  relevant 
engineering  tasks  that  apply  to  the  progr  am. 

4.  Monitor  the  ov  erall  effectiveness  and  progress  of  program  teclmical  efforts. 

5.  Assessment  of  the  contractors  ’  capability  to  meet  the  program  technical  requirements. 


16 


SED  Framework 


SMC  Specially  Engineering  Disciplines 

Lead  Systems  Engineer  and  Systems  Engineering  Staff  Members 

Systems  Engineers  must  orchestrate  all  Specialty  Engineers'  activities  and  products  to  ensure  effective  and 
timely  integration  of  the  disciplines  through  the  full  system  life  cycle.  As  illustrated  in  Figure  1  there  are 
significant  interrelatiousliips  between  the  SEDs  that  require  cross -discipline  interactions,  integration  of 
activities,  and  sharing  of  engineering  products.  This  matrix,  along  with  the  discussions  throughout  this  SED, 
provides  a  means  to  plan  and  perform  effective  integration  of  activities  and  engineering  products. 


Figure  1  Interrelationships  among  SEDs 


Systems  Engineers  must  read  through  and  apply  tliis  entire  SED  document  to: 

1 .  Support  the  Program  or  Project  Manager  to  determine  winch  SEDs  apply  to  the  program. 

2.  Prepare  the  systems  engineering  pi  aiming  and  sufficiently  integrate  into  the  overall  planning  and 
scheduling. 

3.  Facilitate  development  of  the  SEDs  detailed  planning  and  ensure  integration  into  the  Systems 
Engineering  Plan  (SEP  )  and  program  integrated  planning  and  scheduling. 

4.  Ensure  the  engineering  control  activities  are  hilly  supported  by  the  specialty  engineering  disciplines 
and  are  coupled  to  the  program  monitoring  and  control  activities. 

5.  Ensure  all  specialty  and  systems  engineering  contributions  are  timely,  adequate,  consistent,  and 
compliant  to  support  the  engineering,  acquisition,  and  management  activities  and  products. 


SED  Framework 


SMC  Special ty  Engineering  Disciplines 
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Specialty  Engineers 

Specialty  Engineers  must  read,  understand  and  apply  the  information  contained  herein  to  plan  and  execute  their 
SED.  Specialty  Engineers  must  also  read  and  understand  all  other  related  SEDs.  (Figure  1  identifies  the  related 
SEDs.)  Each  Specialty  Engineer  also  determines  which  adjunct  SED  activities  they  must  contribute  to  or 
leverage  off  of  then  plan  and  perform  to  support  the  Program  Office's  objective  for  effective  integrated 
engineering. 

Specialty  Engineers  also  use  this  SED  framework  along  with  available  SMC  instr  uctions  and  guidance  to: 

L  Prepare  the  specialty  engineering  planning  and  sufficiently  integrate  into  the  SEP  and  integrated 
progr  am  planning  and  scheduling. 

2.  Ensure  all  specialty  engineering  contributions  are  timely,  adequate,  consistent,  and  compliant  to 
support  systems  engineering  and  adjunct  specialty  engineering  activities. 

3 .  Support  the  engineering  control  activities  and  program  monitoring  and  control  activities. 

4.  Ensure  all  specialty  engineering  contributions  are  sufficiently  provided  to  support  tire  acquisition 
activities  and  products. 

The  SED  fr  amework  is  first  presented  for  systems  engineering.  The  systems  engineering  framework  represents 
the  standard  framework  that  is  applied  to  each  SED  albeit  expanded  to  capture  each  SED  unique  contribution. 
The  next  section  presents  the  SMC  SEDs  fr  amework  as  applied  to  the  systems  engineering  discipline.  The 
Appendices  provide  the  applied  fr  amework  for  each  SED  typically  performed  on  an  SMC  program 
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SMC  Specially  Engineering  Disciplines 
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Life  Cycle  Systems  Engineering  -  Overarching  Engineering 

The  Systems  Engineer  (SE)  has  the  responsibility  to  perform  the  overarching  engineering  management  and 
control  functions.  The  Systems  Engineer  plans  and  executes  the  comb  hied  engineering  efforts  in  an  integrated 
and  effective  maimer  to  ensure  that  each  SED  contribution  is  timely,  adequate,  consistent  and  compliant. 
Hence,  the  Systems  Engineer  prescribes  and  manages  the  SMC  Program's  engineering  management  and 
technical  controls  processes. 


Systems  Engineering  is  also  considered  a  SED  since  tliis  discipline  includes  specific  engineering  functions: 
requirements  analyses,  interface  analyses,  functional  analyses,  technical  solutions  trades,  systems  studies,  and 
system  element  allocations,  as  well  as  the  integration,  verification,  and  validation  planning  and  execution. 


Applicable  governance,  standards,  and  guidance 

Policy,  directives,  and  instructions  that  mandate  systems  engineering  related  requirements  are  many.  Table  2 
identifies  the  significant  governance,  standards,  and  guidance  which  generally  require  SMC  compliance. 

Table  2  Governance,  standards,  and  guidance  that  shape  tlie  Systems  Engineering  discipline 


Document  No 

Governance  Title 

Issue 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

CJCSM  3170.01 

Operation  of  the  Joint  Capabilities  Integration  and  Development 

System 

24  Jun  03 

AF1 10-601 

Capabilities  Based  Requirements  Development 

30  Jul  04 

AFI 21-108 

Maintenance  Management  of  Space  Systems 

25  Jul  94 

AFi  63-101 

Acquisition  and  Sustainment  Life  Cycle  Management 

22  Mar  11 

AFI  63-01 

Operations  of  Capabilities  Based  Acquisition  System 

29  Jul  05 

AFI  63-1201 

Life  Cycle  Systems  Engineering 

23  Jul  07 

SMC  Sup  AFI  63-1201 

Life  Cycle  Systems  Engineering 

Draft 

SMC  Process  Directives 

Manage  Mission  Assurance:  Develop  System  &  Technology  Req’ts; 
Establish  &  Manage  Eng  Baseline;  V&V  the  System  Baseline 

Document  No 

Standards  Title 

Issue 

|  SMC-S-001  1 

Systems  Engineering  Requirements  &  Products 

|  12  July  10  | 

Document  No 

Guidance  Title 

Issue 

SMC-G-001 

Systems  Engineering  Implementation  Guide 

17  Apr  09 

SMC  SE  HDBK 

SMC  Systems  Engineering  Primer  and  Handbook 

29  Apr  05 

CPATS 

Critical  Process  Assessment  Tool  -  Systems  Engineering 

14  Aug  98 

DAG-DAU 

Defense  Acquisition  Guide  Chapter  4  SE 

h  ttp  ://www  acq  osd .  mi  1/se/pq/i  ndex  h  tml 

Systems  engineering  practices  are  critical  to  acquisition  and  eventually  mission  success.  Requirements  for  a 
systems  engineering  program  are  delineated  in  SMC-S-001.  Systems  Engineering  Requirements  and  Products. 
Tliis  standard  generally  applies  to  all  SMC  acquisitions. 


Systems  Engineers'  Contributions  to  the  Acquisition  Life  Cycle  Framework 

The  DoD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  Sys terns  engineering  contributions  over  tliis  life 
cycle  are  best  represented  within  the  phase  of  acquisition.  Figure  2  provides  the  acquisition  life  cycle 
framework  within  which  Systems  Engineers  perform  as  well  as  the  products  that  Systems  Engineers  must 
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develop  or  contribute  to  their  development.  Tliis  figure  along  with  SMC  -G- 001  delineate  the  Program  Office 
SE  OPR  requirements  to  perform  SE  planning,  support  pie-  and  post-  contract  aw  ard  acquisition  activities,  and 
perform  SE  management  and  engineering  across  the  system  lifecycle.  SMC  Program  Offices  establish  and 
implement  SE  program  strategies  and  objectives  consistent  with  the  tenets  of  appropriate  policies,  SMC 
acquisition  objectives,  and  program  objectives.  The  Program  Office  will  then  develop,  attain  approval  for,  and 
inip  lenient  a  SEP  in  accordance  with  current  DoD  policy.  Tliis  planning  will  be  firmly  based  on  these 
objectives,  strategies,  DoD  mandates,  and  instructions.  An  effective  SE  program  supports  all  of  the  major 
acquisition  activities  through  the  Ml  system  life  cycle.  The  SEP  is  executed  concurrently  with  a  broad  based 
OI  that  documents  the  process  to  perform,  control,  and  inte .grate  all  Systems  Engineering  activities  for  each 
phase  of  acquisition.  The  SMC  Program  Office  SEP  and  OI  will  also  be  based  upon  the  appropriate  program  - 
approved  life  cycle. 


1.  Materiel  Solution  Analysis  (MSA).  During  this  phase  SE 
provides  inputs  to  and  supports  all  program  acquisition 
activities  to  include  the  development  and  preparation  of  a 
cost  model  based  on  anticipated  technical  solutions, 
solicitation/RFP  development  for  Contractor  studies,  and 
proposal  evaluation  activities.  The  SE  also  contributes  to 
the  development  of  the  MSA  Phase  acquisition  products. 


MSA  Phase  -  SMC  Acquisition  Products 


PMD _ 

TPS,  DMS,  TES 
LC  Cost  Estimate 
RFP _ 

FPP,APB,  CCA 
SEP,  LCMP 


TD  Phase  —  SMC  Acquisition  Products 


ASP  TDS,  DMS 


SEP  LCMP,  APB 


LC  Cost  Estimate  Update  /  CARD  Development 


RFP:  SE  objectives  in  SOOr  PWS,  CDRLs;  SMC  and 
Program  standards  -  tailored 


2.  Technology  Development  (ID).  The  SE  provides  inputs 
to  and  supports  ali  program  acquisition  activities  to 
include  updates  to  the  TES  and  inputs  to  the  ASP.  TDS, 
and  development  of  the  TEMP.  The  SE  provides  inputs  to 
the  ODD  and  updates  to  the  cost  model:  development  of 
the  Cost  Analysis  Requirements  Description  (CARD):  and 
solicitation/RFP  development  and  proposal  evaluation  activities.  The  SE  assists  in  the  preparation  of 
contract  requirements  such  as  advanced  technology  demonstrations:  prototyping,  and  developmental  / 
qualification  testing  to  meet  and  Program  Office  objectives  and  requirements.  The  SE  also  contributes  to 
the  development  and  updates  to  the  TD  Phase  acquisition  products  and  assesses  the  effectiveness  of  the 
Contractor  SE  efforts. 


SSP:  evaluation  criteria  for  SE 


EMD  Phase  -  SMC  Acquisition  Products 


Updates  to  ASP,  IDS,  DMS 


SEP  LCMP  APB 


LC  Cost  Estimate  Update  /  CARD  Development 


3.  Engineering  &  Manufacturing  Development  (EMD)* 

The  T&E  Engineer  provides  inputs  to  and  supports  all 
program  acquisition  activities  to  include  updates  to  the 
ASP,  TDS  and  DMS:  inputs  to  the  cost  model  and  CARD 
to  reflect  the  engineering  resources  required:  development 
of  the  APB.  SE  supports  the  solicitation  RFP  development 
and  proposal  evaluation  activities  which  include  providing  the  technical  inputs  including  technical 
requirements,  compliance  standards,  engineering  approaches,  incentives,  and  warranty  programs  to  meet 
program  objectives.  SE  also  contributes  to  the  development  and  updates  to  the  EMD  Phase  acquisition 
products. 


RFP:  SE  objectives  in  SOO;  PWS;  CDRLs;  SMC  and 
Program  standards  -  tailored 


SSP:  evaluation  criteria  for  SE 
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Acquisition  Life-Cycle  Process  for  System 
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Figure  2  Acquisitiuu  life  cycle  process  for  SMC  Systems  Eugiueering 
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4.  Production  &  Deployment  (P&D),  Operations  &  Support 
(O&S).  SE  provides  inputs  to  and  supports  all  program 
acquisition  activities  to  include  updates  to  the  acquisition 
strategy  and  updates  to  the  cost  model  to  reflect  the  actual 
technical  solutions  determined  and  updates  to  the  CARD.  SE 
supports  the  solicitation/RFP  development  and  proposal 
evaluation  activities. 


P&D/O&S  Phases  -  SMC  Acquisition 
Products 


Updates  to  ASP,  TDS,  TEMP,  SEP,  LCMP 

RFP:  objectives  in  S00,  PWS,  CDRLs;  SMC-  SMC 
and  Program  Standards  -  tailored _ 

Detailed  T&E  planning,  SEP,  LCMP,  CARD  updates 


Ch'erarchmg  Engineering  SMC  Specialty  Engineering  Disciplines 


23 


Systems  Engineers'  Contributions  to  the  Engineering  Life  Cycle  Framework 

Systems  Engineers  manage  the  engineering  process  and  activities  depicted  hi  Figure  3 .  Tlie  characteri sties  of  this 
process  are  defined  in  the  SMC  Systems  Engineering  Primer  and  Handbook  and  the  SMC  Systems  Engineering 
Standard  SMC-S-001 .  hi  summary,  this  engineering  life-cycle  framework: 

Provides  engineering  activities  over  a  system  or  product  hfe  cycle 
Aligns  activities  to  an  evolving  technical  baseline 

Aligns  both  the  activities  and  technical  baseline  with  required  technical  review  gates 

Provides  an  overarching  engineering  management  and  control  function  as  defined  within  the  Analysis  & 

Control  process 

This  framework  also  inherently  captures  the  SE  SED  —  specific  engineering  functions  —  requirements  analyses, 
filter  face  analyses,  functional  analyses,  technical  solutions  trades,  requirements  and  system  element  allocations, 
as  well  as  the  integration  and  verification  and  validation  planning  and  execution. 

The  responsibility  to  orchestrate  the  engineering  functions  and  manage  technical  information  typically  resides 
within  the  systems  engineering  organization.  In  performing  the  management  and  control  function,  the  SE 
effectively  integrates  all  engineering  functions  through  the  full  system  hfe  cycle.  The  SE  ensures  technical 
information  advances  through  systematic  control,  collaboration  and  sharing  across  the  organization.  The 
approach  to  concurrently  perform  these  engineering  functions  and  manage  information  is  delineated  in  the  SMC 
Systems  Engineering  Primer  and  Handbook. 

Tools  Selection  and  Use 

Effectiveness  and  efficiencies  are  also  gahied  by  selecting  and  using  an  optimal  mix  of  engineering  tools. 
Generally,  the  SE  leads  the  study  to  determine  the 
selection  and  use  of  engineering  tools.  Each  SED 
supports  this  tool  determination  ensuring  their  unique 
tool  requirements  are  considered  and  ensuring  timely 
exchanges  of  technical  information  among  the  tools 
and  their  respective  databases.  Systems  Engineers 
typically  require  a  suite  of  tools  to  support  the  functions  illustrated  here. 

Engineering  Activities  and  Products  over  the  Life  Cycle 

The  following  subsections  summarize  SE  contributions  to  engineering  activities  and  technical  products  by  DOD 
acquisition  phase.  For  detailed  activities,  requirements  and  products  refer  to  the  SMC  publications  SMC-S-001. 
SMC-G-001. 

1.  Materiel  Solution  Analysis.  During  tliis  phase  the  SE  provides  inputs  to  and  supports  the  Capabilities 
Based  Assessment  (CBA)  process  and  the  Joint  Capabilities  Integration  and  Development  System  (JCIDS) 
process.  The  SE  assists  the  operating  command  to  develop  the  operational  concepts),  prepare  the  ICD, 
STAR,  operational  arcliitectural  products  (OVs,  CVs),  support  AoA  studies,  and  support  threat  assessments. 
The  SE  develops  and  contributes  to 
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Engineering  Analysis  &  Control  (190) 
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development  of  the  MSA  Phase  technical  products.  SE  leads  in  the  development  of  or  supports  the 
technical  strategy  development,  e.g..  TES, 


ASP,  TDS,  and  DMS.  The  SE  manages  the 
system  concept  development  activities:  inputs 
and  factors  for  concept,  arcliitecture, 
technology  studies  and  demonstrations,  and 
trades.  The  SE  ensures  the  development  of 
technology  roadmaps  and  identification  and 
mitigation  of  technical  and  program  risks. 

Technology  Development.  During  tills  phase 
the  SE  continues  to  provide  inputs  to  and 
supports  the  JCIDS  process.  The  SE  also 
initiates  the  set  of  engineering  activities 
liigliiighted  within  the  box  titled  Engineering 
Activities  for  System  &  Segment  Development 
A  Design  Figure  2  to  commence  system 
definition  and  development.  SE  develops  and 
contributes  to  development  of  the  TD  Phase 
technical  products. 

Engineering  &  Manufacturing 

Development.  SE  continues  to  provide  inputs 
to  and  support  the  JCIDS  process.  The  SE  also 
initiates  the  expanded  set  of  engineering 
activities  liigliiighted  within  the  box  titled 
Engineering  Activities  for  Derailed  Design 
Figure  2  to  commence  detailed  systems 
definition  and  development.  SE  develops  and 
contributes  to  the  development  of  the  EMD 
Phase  technical  products. 

Production  &  Deployment,  Operations  & 
Support.  SE  continues  to  provide  inputs  to  and 
supports  the  JCIDS  process.  SE  develops  and 
contributes  to  the  development  of  the  P&D  / 
O&S  technical  products. 


MSA  Phase  —  Technical  Products  Required 


SMC  SE  Technical 
Products 

SE  Contributions  lo  Ollier 
Organizations'  Products 

Technology  Sot  ns  Studies 

Operational  Concepts 

System  Concepts 

Analysis  of  Alternatives  (AoA) 
Studies 

System  Tech  Req  ts  (draft) 

Initial  Capabilities  Doc  (ICD) 
Development,  STAR 

DoDAF  CVs,  OVs 

TD  Phase  -  Technical  Products  Required 

SMC  SE  Technical 

Pi1  □  ducts 

SE  Contributions  to  Other 
Organizations'  Products 

System  &  Arch  Concepts 

Operational  Concepts 

Technology  &  Technical  Sold 
Studies,  and  Trades 

Operational  Assessments, 

STAR,  AoA 

Architectures:  System  & 

Service  DODAF  Views;  ISP 

Capabilities  Development  Doc 
(ODD) 

System  Tech  Req  ts,  TRD,  3RD, 
Specs,  ICDsr  Standards 

DoDAF  CVs,  OVs 

EMD  Phase  -  Technical  Products  Required 

SMC  SE  Technical 
Products 

SE  Contributions  to  Other 
Organizations*  Products 

Update  System  Concept 

Operational  Concepts 

Technical  Studies/  T rades 

Operational  Assessments 

System  Tech  Req’ts,  TRD, 

SRDC  Spec,  ICDs 

Capabilities  Production  Doc 
(CPD) 

SVsr  SvcVs,  TVs,  ISP 

DoDAF  CVs,  OVs 

Engineering  Analyses  Rpts 

V&V  reports 

P&D/O&S  Phases  -  Technical  Products  Required 

SMC  SE  Technical 

Products 

SE  Co utribn lions  to  Other 
Organizations ?  Products 

System  Design  Docs 

Supportability  Analyses  Rpt 

System  Production  Docs 

Operational  Assessments 

Engineering  Analyses  Rpts  ( 
GT&E  results;  performance 
reports;  field  test  reports) 

Transition  &  Fielding  Docs 

Tech  Baseline  Engineenng 
Change  Products 

Analyses  of  production  quality 
reports  and  test  reports 

T&E 
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Systems  Engineers'  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  tlieir  business  model  and  business  and  technical  approach  structure  based 
primarily  on  their  program  objectives,  program  and  technical  challenges,  organizational  structure,  as  well  as 
program  and  engineering  planning  (SEP  plus  detailed  engineering  pi  aiming).  Execution  of  the  planning  is 
typically  defined  through  Program  Office  Operating  Instructions  (OIs).  The  Program  Control  activities  are  also 
defined  within  the  processes  (OIs)  or  as  separate  processes.  SE  provides  full  support  to  define  the  program 
objectives,  establish  a  business  model,  develop  program  pi  aiming  and  schedules,  and  define  and  implement 
program  processes.  SE  must  ensure  the  technical  components  of  the  program  are  appropriately  represented  in 
the  program  plans,  program  schedules,  work  breakdown  schedules,  and  cost  estimates. 

SE  also  ensures  the  timely  reporting  and  integrity  of  the  technical  performance  and  developmental  progress. 
SE  shares  in  the  risk  management  responsibilities  to  identify,  assess,  and  propose  mitigating  actions  of 
technical  risks.  SE  supports  the  program  manager's  problem  identification,  resolution,  and  decision  making 
processes. 

The  SMC  Systems  Engineering  Primer  &  Handbook 
describes  the  role-up  and  relatronsliips  of  the  engineering 
detailed  plans,  schedules,  and  WBS.  as  well  as  the 
integration  of  SE  with  program  and  project  management. 

SE  develops  and  contributes  to  the  development  of  the 
program  management  products  identified  in  the  table  to 
the  right. 


SE  Contributes  to  the  development  &  updates 
to  SMC  Program  Management  Products 


PMD 


IMP,  IMS  WBS 


Decision-making  &  problem  solving  inputs 


Technical  progression  and  issues  reporting 


Life-Cycle  Cost  Estimate  (CARDs) 


Processes  (OIs) 


Risk  Management  Inputs 
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Appendix  A  -  Test  and  Evaluation  Engineering 

Test  and  Evaluation  (T&E)  is  a  pervasive  Program  Office  discipline  that  is  essential  for  the  successful 
acquisition  of  space,  missile,  and  ground  systems  that  ultimately  leads  toward  hill  verification  of  die  technical 
baseline  of  the  system,  allocated,  and  design  requirements  and  validation  of  the  operational  capabilities.  The 
SMC  Program  Office  T&E  Engineer  stand-ups  and  executes  the  T&E  program.  The  T&E  Engineer  initially 
develops  the  SMC  Program's  test  strategy  in  the  Materiel  Solution  Ana  lysis  (MSA)  phase  and  initiates  and 
implements  the  test  planning  beginning  hi  the  Technology  Development  (TD)  and  succeeding  phases  of 
acquisition.  The  T&E  Engineer  strategies,  plans,  coordinates,  and  manages  the  T&E  program  and  ensures 
progress  through  technology  demonstrations,  prototyping,  qualification  testing,  production  testing,  integration 
testing,  pre  and  post  launch  systems  check-out,  and  operational  testing  dirough  the  development,  production, 
operation,  and  sustainment  of  a  system  or  product. 

Throughout  the  program  acquisition  life-cycle,  the  T&E  Engineer  ensures  evolving  technologies  and  design 
solutions  meet  system  and  design  specifications  and  the  final  design  meets  operational  requirements  and 
constraints.  The  T&E  Engineer  organizes  and  integrates  T&E  activities,  resources,  and  information  within 
statutory  and  regulatory  guidelines  and  sound  engineering  principles.  The  T&E  Engineer  ensures  the  baseline 
test  requirements  are  appropriately  established,  resources  are  available,  and  the  events  are  incorporated  in  the 
contractors  Integrated  Master  Schedule  (IMS)  and  government  master  schedules.  The  T&E  Engineer  s hives  for 
the  identification  and  elimination  of  inherent  or  latent  defects,  process  (e.g.  workmanship),  and  procedural 
deficiencies  to  ensure  a  liigh  level  of  confidence  in  the  progr  ession  of  the  system  development  efforts  to  meet 
the  intended  reliability  growth  targets,  performance  requirements,  and  Total  Ownersliip  Cost  (TOC)  targets. 
The  T&E  Engineer  coil  a  borates  with  the  Program  Office  Systems  Engineering  organization  and  the  acquisition 
community,  and  provides  the  evaluation  results  including  deficiency  and  risk  discovery  and  remedies. 

The  T&E  Engineer,  Air  Force  Operational  Test  and  Evaluation  Center  (AFOTEC)  (or  the  lead  operational  test 
organization)  and  stakeholders  prepare  the  Integrated  Test  Team  (ITT)  charter  and  conduct  the  ITT  through  all 
progr  am  phases.  The  T&E  Engineer  assures  that  ail  stakeholder  requirements  are  satisfied  by  working  with  the 
ITT  as  a  cross-functional  team. 

Applicable  governance,  standards,  and  guidance 

Policy,  directives,  and  instructions  that  govern  T&E  are  included  in  a  wide  range  of  mandates  including  those 
providing  requirements  for  acquisition,  systems  engineering,  information  assurance,  software  development, 
safety,  and  others.  Table  3  below  identifies  significant  governance  and  standards  which  require  SMC 
compliance  for  T&E  as  well  as  implementation  guidance. 

DoDD  5000.01  directs  that  T&E  is  integrated  throughout  the  defense  acquisition  process  and  that  “test  and 
evaluation  shall  be  structured  to  provide  essential  information  to  decision-makers,  assess  attainment  of 
technical  performance  parameters,  and  determine  whether  systems  are  operationally  effective,  suitable, 
survivable,  and  safe  for  intended  use.  The  conduct  of  test  and  evaluation,  integrated  with  modeling  and 
simulation,  shall  facilitate  learning,  assess  teclmology  maturity  and  interoperability,  facilitate  integration  into 
fielded  forces,  and  confirm  performance  against  documented  capability  needs  and  adversary  capabilities  as 
described  in  the  system  threat  assessment.’1 
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DoDI  5000.02  Enclosure  6,  Integrated  T&E*  details  specific  test  and  evaluation  procedures.  CJCSI  3170.01G 
instructs  that  KPPs  must  be  testable  to  enable  feedback  from  test  and  evaluation  efforts  to  the  requirements 
process. 


AFI  99-103  provides  the  primary  T&E  governance  to  implement  DoDD  5000.01  and  DoDI  5000.02.  The 
standards  listed  in  the  table  below  provide  typical  requirements  and  guidelines  for  T&E.  The  SMC  design 
standards  generally  provide  T&E  requirements  specific  to  the  technology.  Line -Replace able  Unit  (LRU)  type, 
and  device.  Hence,  the  more  detailed  test  requirements  are  largely  determined  during  the  system  development 
and  design  process. 

TabSe  3  Governance,  standards,  and  guidance  that  shape  the  Test  and  Evaluation  Engineering  discipUne 


Document  No 

Governance  Title 

Issue 

DoDD  5000.01 

Defense  Acquisition  System 

20  Nov  07 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

CJCSI  31 70.01  G 

Joint  Capabilities  Integration  and  Development  System 

1  Mar  09 

AFPD  99-1 

Test  &  Evaluation  Process 

22  Jul  93 

ATI  99-103 

Capability-Based  Test  &  Evaluation 

20  Mar  09 

AF1 10-601 

Operational  Capability  Requirements  Development 

12  Jul  10 

AFI  63-101 

Acquisition  And  Sustainment  life  Cycle  Management 

22  Mar  11 

Document  No 

Standards  Title 

Issue 

SMC-S-004 

Independent  Structural  Loads  Analysis 

13  Jun  08 

SMC-S-005 

Space  Systems  -  Flight  Pressurized  Systems 

03  Jun  09 

SMC-S-006 

Solid  Rocket  Motor  Case  Design  And  Test 

13 Jun  08 

SMC-S-007 

Space  Battery 

13  Jun  08 

SMC-S-008 

Electromagnetic  Com  pate  bility  Requirements  For  Space  Equipment 

And  Systems 

13 Jun  08 

SMC-S-009 

Parts,  Material,  and  Processes  Control  Program  for  Space  &  Launch 
Vehicles 

12  Jan  09 

SMC-S-010 

Technical  Requirements  for  Electronic  Parts,  Materials,  and 

Processes  for  Space  and  Launch  Vehicles 

12  Jan  09 

SMC-S-011 

Parts,  Materials,  &  Processes  Control  Program  for  Expendable 

Launch  Vehicles 

13 Jun  08 

SMC-S-012 

Software  Development  For  Space  Systems 

13  Jun  08 

SMC-S-013 

Reliability  Program  For  Space  Systems 

13 Jun  08 

SMC-S-016 

Test  Requirements  For  Launch,  Upper-Stage  &  Space  Vehicles 

13  Jun  08 

SMC-S-017 

Lithium-Ion  Battery  For  Spacecraft  Applications 

13 Jun  08 

SMC-S-018 

Lithium-Ion  Battery  For  Launch  Vehicle  Applications 

13  Jun  08 

SMC-S-020 

Technical  Requirements  For  Wiring  Harness,  Space  Vehicle 

03  Jun  09 

MIL-STD461F 

Electromagnetic  Emissions  and  Susceptibility,  Requirements  for  the 
Control  of  Electromagnetic  Interference 

10  Dec  07 

MIL-STD-810G 

Environmental  Engineering  Considerations  And  Laboratory  Tests 

31  Oct  08 

MIL-STD-1 833 

Test  Requirements  For  Ground  Equipment  And  Associated  Computer 
Software  Supporting  Space  Vehicles 

13  Nov  89 

M1L-STD-1 542B 

Electromagnetic  Compatibility  And  Grounding  Requirements  For 

Space  System  Facilities 

15Nov91 

AIAA  S-080-1998 

Space  Systems-MetalEic  Pressure  Vessels,  Pressurized  Structures 
and  Pressure  Components 

1  Jan  99 

AIAAS-081-2000 

Space  Systems-Composite  Overlapped  Pressure  Vessels 

1  Jan  01 

AIAA  S-1 10-2005 

Spa  ice  Systems-Structures,  Structural  Components  and  Structural 
Assembly 

12  Jul  05 

AIAA  S-1 14-2005 

Moving  Mechanical  Assemblies  for  Space  and  Launch  Vehicles 

30  Jun  05 

AIM  S-1 13-2005 

Cnteria  for  Explosive  Systems  &  Devices  Used  on  Space  Vehicles 
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AIM  S-1 11-2005 

Qualification  and  Quality  Standards  for  Space -Qua lifted  Solar  Cells 

26  Sept  05 

AIM  S-1 12-2005 

Qualification  and  Quality  Req’ts  for  Space-Qualified  Solar  Panels 

26  Sept  05 

Document  No 

Guidance  Title 

Issue 

MIL-HD8K-340A,  V  III 

Test  Reqts  for  Launch,  Upper  Stage  and  Space  Vehicles:  Application 
Guidelines 

01  Apr  99 

AFSPCMAN  91-710 

Range  Safety  User  Requirements  Manual 

1  Jul  04 

DAG 
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T&E  Engineers'  Contributions  to  the  Acquisition  Life  Cycle  Framework 

The  DoD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  The  T&E  Engineer  contributions  over  this  life 
cycle  are  best  represented  within  the  acquisition  phase.  Figure  4  provides  the  acquisition  life  cycle  framework 
within  which  T&E  Engineers  perform  as  well  as  the  products  that  they  must  develop  or  contribute  to  the 
system  development.  This  figure  along  with  the  governance  sited  above  such  as  AEI 99-103,  Capability-Based 
Test  &  Evaluation  provide  the  requirements  to  perform  T&E  planning,  stand-up  and  conduct  the  ITT,  support 
pre  and  post  contract  award  acquisition  activities,  and  perform  T&E  management  and  engineering  across  the 
system  lifecycle.  The  SMC  Program  Office  establishes  and  implements  T&E  program  strategies  and  objectives 
consistent  with  SMC  acquisition  and  program  objectives.  From  the  T&E  program  strategies  the  Program 
Office  develops,  approves,  and  incorporates  detailed  T&E  planning  into  the  Test  and  Evaluation  Master-  Plan 
(TEMP),  Systems  Engineering  Plan  (SEP)  and  higher  level  integrated  pi  arming  (e.g..  Integrated  Master  Plan, 
Life -Cycle  Master  Plan,  Life -Cycle  Sustainment  Plan)  hi  accordance  with  DoD  policy  and  Program  Office 
practices.  Hence,  T&E  planning  is  firmly  based  on  program  objectives  and  technical  requirements,  strategies, 
and  DoD  mandates  and  instructions. 

An  effective  T&E  program  supports  ail  of  the  major  acquisition  activities  through  the  full  system  life  cycle. 
The  planning  sufficiently  defines  the  T&E  program  to  achieve  the  T&E  and  overall  program  objective  s/goals 
and  requirements:  specifies  tasks  and  functions  to  be  performed,  timing  of  tasks,  resources  required,  products 
to  be  developed,  and  forms  the  basis  for  the  development  of  the  program  T&E  Operating  Instruction  (OI).  The 
T&E  planning  and  OI  are  then  reflected  appropriately  in  the  WBS.  IMS,  and  other  program  documents  that 
address  T&E  related  elements.  The  T&E  planning  is  executed  concurrently  with  the  Program  Office  OI  that 
documents  the  process  to  perform,  control,  and  integrate  all  T&E  activities  for  each  phase  of  acquisition. 

The  SMC  Program  Office  T&E  plaruung  (usually  contained  hi  the  SEP  arid  the  detailed  T&E  program 
planning)  and  OI  are  to  be  based  upon  the  appropriate  program-approved  life  cycle.  SMC  Program  Offices 
establish  and  implement  T&E  program  strategies  and  objectives  consistent  with  the  tenets  of  appropriate 
policies,  SMC  acquisition  objectives,  and  program  objectives. 
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1.  Materiel  Solution  Analysis.  Duiing  this  phase  the  T&E 
Engineer  with  community  involvement  formulates  the 
T&E  Strategy  (TE&),  Technology  Development  Strategy 
(TDS),  and  provides  inputs  to  and  supports  acquisition 
activities  to  include  development  of  acquisition  strategy, 
technology  development  strategy,  and  data  strategies. 

The  T&E  Engineer  provides  inputs  to  the  cost  estimates, 
solicitation/  Request  for  Proposal  (REP)  development  for 
Contractor  studies,  and  proposal  evaluation  activities, 
development  of  the  MSA  Phase  acquisition  products. 

2.  Technology  Development.  Tlie  T&E  Engineer  provides 
inputs  to  and  supports  all  program  acquisition  activities  to 
include  inputs  to  the  Acquisition  Strategy  and 
development  of  the  TEMP.  The  T&E  Engineer  provides 
updates  to  the  cost  model;  development  of  the  Cost 
Analysis  Requirements  Description  (CARD):  aud 
solicitation/RFP  develop  merit  and  proposal  evaluation 
activities.  The  T&E  Engineer  assists  hi  the  preparation  of 
contract  requirements  such  as  advanced  technology 
demonstrations:  prototyping,  and  developmental  /  qualification  testing  to  meet  T&E  and  Program  Office 
objectives  and  requirements.  The  T&E  Engineer  also  contributes  to  the  development  aud  updates  to  the 
TD  Phase  acquisition  products.  The  T&E  Engineer  assesses  the  effectiveness  of  the  Contractor  T&E 
efforts. 

3.  Engineering  &  Manufacturing  Development.  The  T&E 
Engineer  provides  inputs  to  and  supports  all  program 
acquisition  activities  to  include  updates  to  the  Acquisition 
Strategy  Panel  (ASP)  and  Data  Management  Strategy 
(DMS);  updates  to  the  TEMP:  inputs  to  the  cost  model 
and  CARD  to  reflect  the  test  events  and  resources 
required:  inputs  to  the  Acquisition  Program  Baseline 
(APB  i, 

T&E  strategies  are  likely  integral  to  the  reliability  growth 
strategies  as  well  as  strategies  to  achieve  system 
performance.  The  strategies  now  extend  to  ensure  full 
verification  and  validation  (V&V)  of  the  system  design  determined  through  system  trades  and  engineering 
analyses.  The  T&E  Engineer  supports  the  preparation  of  contract  requirements  such  as  T&E  performance 
work  statements;  identification  and  tailoring  of  the  compliance  test  standards;  preparation  of  the  T&E 
related  Contract  Data  Requirements  Lists  (CDRLs)  for  submission  of  test  plans,  procedures,  reports; 
government  furnished  test  equipment  and  facilities;  government  monitoring  of  tests.  The  T&E  Engineer 
also  contributes  to  the  development  and  updates  to  the  EMD  Phase  acquisition  products. 


EMD  Phase  -  SMC  Acquisition  Products 


Updates  to  ASP,  DMS _ 

Updates  to  TEMP _ 

Detailed  T&E  planning;  Inputs  to  SEP,  ICMP _ 

LC  Cost  Estimate  Update  /  CARD  Development _ 

inputs  to  CPD _ _ _ 

Inputs  to  APB:  T&E  objectives  &  related  concept 
descriptions _ 

REP:  T&E  objectives  in  the  S00;  T&E  tasks  in  PWS, 
T&E  data  products  in  CDRLs;  SMC-  T&E  standards  - 
tailored _ 

SSP  evaluation  criteria  for  T&E _ 

Updates  to  CARD 


MSA  Phase  -  SMC  Acquisition  Products 

Inputs  ASP,  TDS,  DMS 

Prepare  TES 

Inputs  to  SEP,  LCMP,  CARD 

Inputs  to  LC  Cost  Estimate 

Inputs  to  APB 

REP:  T&E  objectives  in  the  S00;  T&E  tasks  in  PWS, 
T&E  data  products  in  CDRLs;  SMC-  T&E  standards 

The  T&E  Engineer  also  contributes  to  the 

1  TD  Phase  —  SMC  Acquisition  Products 

Updates  to  ASP,  DMS  TEMP  preparation 

Detaiied  T&E  planning;  Inputs  to  SEP,  LCMP 

LC  Cost  Estimate  Update  /  CARD  Development 

Inputs  to  APB:  T&E  objectives  &  related  concept 
descriptions 

RFP;  T&E  objectives  in  the  S00;  T&E  tasks  in  PWS, 
T&E  data  products  in  CDRLs;  SMC-  T&E  standards  - 
tailored 

SSP:  evaluation  cnteria  for  T&E 
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4*  Production  &  Deployment,  Operations  &  Support, 

The  T&E  Engineer  provides  inputs  to  and  supports  ail 
program  acquisition  activities  to  include  updates  to  the 
ASP  and  DMS:  updates  to  the  TEMP:  inputs  to  the  cost 
model  and  CARE*  to  reflect  the  test  resottrces  required: 
inputs  to  the  APB.  The  T&E  Engineer  supports  the 
preparation  of  contract  requirements  such  as  T&E 
performance  work  statements:  identification  and  tailoring 
of  the  compliance  test  standards:  preparation  of  the  T&E  related  CDRLs  for  submission  of  test  plans, 
procedures,  reports;  government  furnished  test  equipment  and  facilities:  government  monitoring  of  tests. 

The  T&E  Engineer  identifies  other  contract  requirements:  incentives  programs:  production  and  operational 
test  &  demo  requirements;  and  field  performance  and  sustainment  analyses  to  meet  T&E  objectives.  The 
T&E  Engineer  ensures  successful  validation  of  the  intended  operational  capabilities  through  operational 
test  and  evaluation.  The  T&E  Engineer  supports  Developmental  Test  and  Evaluation  (DT&E),  Initial 
Operational  Test  and  Evaluation  (IOT&Ef  Operational  Test  and  Evaluation  (OT&E),  Initial  Operational 
Capability  (IOC)  and  Full  Ope  rational  Capability  (FOC)  to  meet  community  T&E  objectives. 

T&E  Engineers'  Contributions  to  the  Engineering  Life  Cycle  Framework 

Relationship  to  the  SE  Organization 

The  T&E  Engineer  plans  and  executes  essential  T&E  engineering  and  management  efforts  within  the  context 
and  full  support  to  the  overarching  Systems  Engineering  fimction.  The  T&E  Engineer  ensures  that  each  T&E 
contribution  is  timely,  adequate,  consistent,  and  compliant.  The  T&E  Engineer  ensures  that  their  contributions 
are  cliamieled  through  the  Systems  Engineering  Analyses  and  Con  fro  I  and  V&V  activities.  Systems  Engineers 
manage  the  engineering  process  and  activities  depicted  in  Figure  3  while  the  T&E  Engineer  contributes  to  this 
process  by  supporting  concept  and  architecture  development  and  analyses:  modeling  and  simulation  efforts: 
and  technology  development;  design  trades,  V&V,  and  sustainability  analyses.  The  T&E  Engineer  supports 
the  requirements  analyses  and  allocation  process,  to  assure  that  the  specifications  are  well  stated,  are  testable, 
and  tliat  associated  test  scenarios  are  unambiguous.  Further,  the  T&E  Engineer  develops/derives  verification 
and  test  requirements.  The  scope  of  the  T&E  Engineers  activities  with  system  engineering  includes  evaluation 
of  verification  and  validation  of  interfaces,  functions,  and  integration  and  test  at  the  component,  segment  and 
system  levels.  The  T&E  Engineer  ensures  specification  test  strategies,  plans,  and  methodologies  developed  by 
System  Engineering  are  adequate.  The  T&E  Engineer  evaluates  kite  grated  test  plans  and  procedures  for  space 
system  hardware,  software,  and  information  exchanges  to  verify/vahdate  developmental,  qualification, 
acceptance,  and  operational  testing  requirements.  The  T&E  Engineer  ensures  results  of  testing  are  applied  to 
the  overall  engineering  effort  through  systematic  control,  collaboration  and  sharing  across  the  organization  to 
facihtate  system  development  and  imple mentation. 

Relationship  to  other  SEDs 

T&E,  by  the  nature  of  their  function,  must  interface  with  every  specialty  discipline  involved  with  the  design, 
development,  nianu factoring,  deployment  and  operation  of  a  system  to  ensure  that  then  requirements  and  test 
needs  are  addressed  as  part  of  the  T&E  program.  For  example,  the  T&E  Engineer  works  with: 


P&D  /  O&S  Phase  -  SMC  Acquisition 
Products 


Updates  to  ASP,  TEMP _ 

Detailed  T&E  planning;  Inputs  to  SEP,  LCMP _ 

RFP:  T&E  objectives  in  the  S00;  T&E  tasks  in  PWS, 
T&E  data  products  in  CDRLs;  SMC-  T&E  standards  - 
tailored _ 

Detailed  T&E  planning,  SEP,  LCMP  updates _ 

CARD  update 
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•  System  Safety  to  plan  and  conduct  tests  of  safety  devices,  perform  demonstrations  for  manufacturing 
and  production,  and  operations  and  maintenance  safety  procedures 

•  Reliability  Engineers  to  establish  and  conduct  reliability  testing  and  implement  the  reliability  growth 
program. 

•  Information  Assurance  Engineer  to  demons  date  integrity  of  system  information  is  safeguarded:  anti- 
spoofmg  measures  are  effective. 

•  Manufacturing  &  Producibility  Engineer  to  develop  and  implement  production  tests,  e.g.,  Is1  article, 
acceptance  tests. 

•  Design  Engineering  in  a  multi-disciplinary  process  during  all  program  phases  to  evaluate 
requirements  and  validate  the  flow-down  of  verification  methods  for  credible  test  and  evaluation 
solutions  for  spacecraft,  payload,  C3  data  processing,  and  mission  operations. 

•  Integrated  Logistic  Support  to  plan,  prepare  for  and  conduct  maintenance  test  demonstrations.  Built- 
in-Test  (BIT),  diagnostics  development  and  verification. 

•  Quality  Assurance  to  assist  to  define  and  validate  process  controls  and  quality  conformance 
verification. 

•  Prognostics  Health  Management  to  assist  in  architecting  and  validating  diagnostics  capabilities. 

•  Software  Engineer  to  develop  prototyping  approaches,  plan  and  conduct  software  testing 

Tools  Selection  and  Use 

The  T&E  Engineer  considers  effectiveness  and 
efficiencies  gained  by  selecting  and  using  the 
best  choice  of  T&E  tools  needed  to  support 
requirements  for  test,  modeling,  simulation, 
prototyping,  test  data  evaluation,  information 
sharing,  automated  data  exchanges  with  other  tools,  and  other  considerations. 

Engineering  Activities  and  Products  over  the  Life  Cycle 

The  Program  Office  and  the  operational  test  organization  determine  the  full  scope  of  T&E  activities,  events, 
and  products.  There  are  many  aspects  of  the  T&E  program  that  are  required  to  ensure  successful 
developmental  and  operational  V&V  of  a  system.  The  following  subsections  delineate  T&E  contributions  to 
engineering  activities  and  technical  products  by  DoD  acquisition  phase. 

1 .  Materiel  Sotutiou  Analysis*  During  this 
phase  the  T&E  Engineer  prepares  the  ITT 
Charter  and  conducts  the  ITT.  The  T&E 
Engineer  develops  the  TES  and  provides 
inputs  to  the  ASP,  TDS,  and  DMS.  The 
T&E  Engineer  supports  the  concept 
development  activities  providing  inputs  and 
factors  for  concept,  architecture,  technology 
studies  and  demonstrations,  and  trades.  The 
T&E  Engineer  supports  the  development  of 
teclinology  roadmaps  and  assists  to  identify  and  mitigate  tecluiical  and  program  risks.  The  T&E  Engineer 
assists  the  operating  command  to  develop  the  operational  concept(s).  prepare  the  ICD  STAR*  operational 


MSA  Phase  —  Technical  Products  Required 


SMC  T&E  Technical 

Pro  d  uel  s 

T&E  Contributions  to  Other 
Organizations'  Products 

ITT  Charter 

Inputs  to  Operational  Concepts 

TES;  Inputs  ASP,  TDS,  DMS 

Inputs  to  ICD,  STAR 

T&E  inputs  and  factors  for 
concept,  architecture,  technology 
studies,  and  trades 

Inputs  to  AoA  Studies 

Roadmap  inputs  -  mitigations  of 
T&E  nsks 

DoDAF  CVs,  OVs 

Inputs  to  SEP,  LCMP,  CARD 

Typical  T&E  Functions  Requiring  Tools 


Modeling  &  Simulations _ 

Test  Requirements  Development _ 

Test  Automation _ 

Test  assets  tracking,  scheduling,  assessments 

Anomaly  /  deficiency  status  tracking  and  resolution 
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architectural  products  (OVs,  CVs),  siippoit  AoA  studies,  and  tlireat  assessments.  The  T&E  Engineer 
contributes  to  development  of  the  MSA  Phase  technical  products. 

2.  Technology  Development.  During  this 
phase  the  T&E  Engineer  continues  to 
provide  inputs  to  and  supports  the  JCIDS 
process.  The  T&E  Engineer  also  supports  all 
the  engineering  activities  highlighted  within 
the  box  titled  Engineering  Activities  for 
Deielopment  dr  Design  Figure  4  to 
commence  system  definition  and 
development.  The  T&E  Engineer  develops 
and  contributes  to  development  of  the  TD 
Phase  technical  products. 

The  T&E  Engineer  supports  the  concept, 
architectural,  tecimolo gy  development,  and 
engineering  trades  and  analyses  to  ensure  the 
concept,  architectural,  technology  and 
design  solutions  are  determined: 

•  Tlnough  the  appropriate  evaluations,  analyses  and  trades,  mode  hog  and  simulation  (M&S)  efforts, 
tests,  demonstrations. 

•  With  consideration  of  the  requir  ed  test,  M&S,  and  other  resources 

•  With  the  complement  of  approaches,  including  test,  M&S.  demonstration,  to  achieve  technical 
maturity 

•  hi  conjunction  with  the  complementaiy  verification  and  validation  (V&V)  requirements 

The  T&E  Engineer  participates  in  technology  maturation  activities  throughout  this  phase.  The 
responsibility  includes  assessing  the  risk  mitigation  Ltbiun-down'?  approach,  establishing  the  adequacy  of 
hardware  and  software  prototyping,  M&S  and  resources.  The  T&E  Engineer  assesses  the  results  and 
provides  reconmienda  tions  for  transition  to  higher  maturity  levels. 

Easing  the  TES  as  a  baseline,  the  T&E  Engineer  prepares  and  coordinates  the  TEMP  with  all  stakeholders 
to  provide  the  roadmap  for  DT&E  and  OT&E.  The  TEMP  addresses  the  use  of  resources,  measures  of 
effectives  and  suitability1',  defines  the  critical  operational  issues  and  provides  program  compliance  direction 
for  T&E  to  assure  the  system  is  capable  of  meeting  its  requirements  and  implementing  the  concept  of 
operations.  The  T&E  Engineer  plans  and  documents  the  M&S  approach,  and  prepares  the  M&S  Support 
Plan  in  conjunction  with  System  Engineering.  M&S  wifi  be  used  to  verify  and  validate  system  capabilities 
tluoughout  DT&E  and  OT&E. 


TD  Phase  —  Technical  Products  Required 


SMC  T&E  Technical 

Products 

T&E  Contributions  to  Other 
Organizations’  Products 

ITT  charter  update 

Inputs  to  Operational  Concepts 

TEMP 

Inputs  to  CDD,  STAR 

Inputs  ASP  ADS,  QMS 

T&E  inputs  and  factors  for 
concept,  architecture,  technology 
studies,  and  trades 

Inputs  to  AoA  Studies 

Roadmap  inputs 

DoDAF  CVs,  OVs 

Architectural  inputs:  System  & 
Service  DODAF  Views;  ISP 

T&E  verification  requirements 
inputs  &  evafs:  TRD,  SRD,  Specs 

RFP  inputs;  S00,  PWS  Tasks, 
CDRLs,  DIDs;  T&E  standards 

inputs  to  detailed  eng  planning, 
M&S  Support  Plan,  SEP,  LCMP 
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3.  Engineering  &  Manufacturing 
Development,  During  tills  phase  the  T&E 
Engineer  continues  to  provide  inputs  to  and 
supports  the  JCIDS  process.  The  T&E 
Engineer  also  supports  all  the  engineering 
activities  highlighted  within  the  box  titled 
Engineering  Activities  for  Development  & 

Design  Figure  4  to  commence  detailed 
system  design  and  development.  The  T&E 
Engineer  develops  and  contributes  to 
development  of  the  EMD  Phase  tecliuical 
products. 

The  T&E  Engineer  updates  and  coordinates 
the  TEMP  and  M&S  Support  Plan.  The  T&E 
Engineer  assists  to  determine  test 
requirements  for  long  lead  procurements  and 
GEE.  The  T&E  Engineer  supports  the  engineering  requirements  development  and  design  efforts  to  ensure 
the  design  solutions  are  determined: 


EMD  Phase  -  Technical  Pro  ducts  Required 


SMC  T&E  Technical 

Pro  flucts 

T&E  Contributions  to  Other 
Organizations’  Products 

ITT  charter  update 

Inputs  to  Operational  Concepts 

Updates  to  TEMP,  ASP,  TDS 

Inputs  to  CPD,  STAR 

Architectural  inputs:  System  & 
Service  DODAF  Views;  ISP 

T&E  inputs  and  factors  for  design 
analyses  and  trades 

Inputs  to  AoA  Studies 

T&E  verification  requirements 
inputs  &  evals:  TRD,  SRD,  Specs 

Inputs  to  detailed  eng  planning, 
SEP,  LCMP,  CARD 

Input  to  DoDAF  AVs,  CVs,  DIVs, 
OVs 

RFP  inputs:  S00,  PWS  Tasks, 
CDRLs,  DIDs;  T&E  standards 

Evals  of  test  plans,  procedures;  & 
results;  Assessments  of 

integration,  fielding,  sustain  docs 

System  and  Service  DODAF 
Views;  TVsr  ISP  inputs 

•  Through  the  appropriate  evaluations,  analyses  and  trades,  modeling  and  simulation  effoits.  tests, 
demonstrations. 

•  With  consideration  of  the  required  test  and  M&S  equipment,  test  software,  test  sites  and  facilities, 
personnel  resources 

•  To  attain  commitments  and  schedule  resources 

•  hi  conjunction  with  the  complementary  verification  and  validation  requirements 

•  With  consideration  of  test  requirements  for  integration,  field  mg  ,  and  sustainment  test  assets 

The  T&E  Engineer  ensures  the  adequacy  of  the  entire  verification  program  to  include  contractual 
establislunent  and  adherence  to  qualification  and  acceptance  testing  to  include  bottoms -up  developmental 
qualification  testing  of  materials,  piece  parts,  components,  assemblages  and  integration  of  assemblages: 
reliability  growth  testing,  safety  demonstrations,  maintainability  demonstrations,  and  aging  and 
surveillance  testing  of  limited  life  materials  and  parts.  The  T&E  Engineer  ensures  adequate  qualification 
of  critical  manufacturing  processes. 

The  T&E  facilitates  or  supports  an  effective  failure  reporting  and  collective  action  system  (FRACAS), 
problem  identification  and  resolution  process,  and  risk  management  program.  The  T&E  Engineer  reports, 
validates,  tracks,  evaluates  and  responds  to  deficiency  reports  in  accordance  with  TO  GO-35D-54,  USAF 
Deficiency  Reporting  and  Investigating  System.  The  T&E  Engineer  compiles  and  scores  test  data  and 
implements  and  conducts  the  Test  Data  Scoring  Board  (TDSB). 

The  T&E  Engineer  assists  the  PM  to  prepare  the  certification  for  Operational  Test  &  Evaluation  (OT&E), 
and  conduct  the  OT&E  program.  T&E  efforts  also  concentrate  on  refining  and  finalizing  the  Bite  grated 
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Test  Plans  to  perform  qualification  and  acceptance  testing  required  dining  Production  Deployment  and 
Operations  Support  Phase. 

4*  Production  <&  Deployment,  Operations  & 

Support*  The  T&E  Engineer  continues  to 
provide  inputs  to  and  supports  the  JCIDS 
process.  The  T&E  Engineer  continues  to 
oversee  the  DT&E  program  tluough  the 
systems  engineering  process  to  perform 
V&V  and  support  development  and 
performance  of  the  IOT&E  and  OT&E 
program.  The  T&E  Engineer  develops  and 
contributes  to  the  development  of  the 
Production  and  Deployment  /  Operations  and  Support  Phase  technical  products.  The  T&E  Engineer  assists 
the  PM  hi  the  preparation,  coordination  and  issuance  of  the  Certificate  of  System  Readiness  to  enter 
OT&E. 

The  T&E  Engineer  continues  to  ensure  the  adequacy  of  the  entire  verification  program  to  include 
contractual  establishment  and  adherence  to  qualification  and  acceptance  testing  to  include  bottoms -up 
quality  conformance  and  acceptance  testing  of  materials,  piece  parts,  components,  assemblages; 
production  acceptance  and  first  article  testing:  reliability"  growth  testing,  integration  testing,  and  aging  and 
surveillance  testing. 

The  T&E  Engineer  continues  to  support  the  engineering  requirements  development  and  design  efforts  to 
ensure  the  design  solutions  are  determined: 

•  Tluough  the  appropriate  evaluations,  analyses  and  trades,  modeling  and  simulation  effoits,  tests, 
demonstrations. 

•  With  consideration  of  the  required  production  test  equipment,  test  software,  test  sites  and  facilities, 
personnel  re  som  e  es 

•  To  attain  commitments  and  schedule  resources 

•  In  conjunction  with  the  complementary  verification  and  validation  requir  ements 

•  With  consideration  of  test  requirements  for  integration,  fielding,  and  sustainment  test  assets 

The  T&E  facilitates  or  supports  an  effective  FRACAS,  problem  identification  and  resolution  process,  and 
risk  management  program.  The  T&E  Engineer  reports,  validates,  tracks,  evaluates  and  responds  to 
deficiency  reports  LAW  TO  00-35D-54,  USAF  Deficiency  Reporting  and  Investigating  System.  The  T&E 
Engineer  continues  to  compile  and  score  test  data  and  conduct  the  TDSB. 

After  system  deployment,  T&E  provides  teclmical  support,  documentation,  and  test  planning  and 
evaluation  support  to  supportability  assessments,  system  modifications,  sparing  procurements;  and 
certifications. 


P&D  /  O&S  Phase  -  Technical  Products  Required 


SMC  T&E  Technical 
Products 

T&E  Contributions  to  Other 
Organizations  ■  Products 

Inputs  to  tech  baseline 
engineering  changes 

Supportability  Analyses  Rpt 

Analyses  of  production  quality 
reports  and  test  reports 

Operational  Assessments 

Analyses  of  OT&E  results; 
performance  reports;  field  test 
reports 

Survivability  Assessments 

Inputs  to  FRACAS 

Transition  &  Fielding  Docs 

T&E 
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T&E  Engineers'  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  their  busbies s  model  and  approach  based  primarily  on  program  objectives, 
technical  challenges,  organizational  structure,  and  required  engineering  planning  including  test  and  evaluation 
for  cost-effective  execution. 

T&E  Engineer  supports  Program  Management  by  initially  deveiopmg  an  mtegrated  test  strategy  for  the 
program,  scopmg  the  T&E  efforts  over  the  acquisition  fife -cycle  phases,  then  developing  and  implementing  the 
T&E  program  plaimnig  to  implement  the  required  statutes  and  regulations  and  to  achieve  Program  Office 
objectives  and  requirements.  The  planning  defines  the  T&E  tasks  and  functions  to  be  performed  and  products 
to  be  developed:  timing  of  tasks,  task  outputs,  resources  (skills,  tools,  test  equipment  and  facilities).  The  T&E 
Engineer  plans  tasks  to  integrate  T&E  activities  within  the  Program  Office,  test  organizations,  operational 
community,  and  between  Contractors  and  stakeholders.  The  T&E  Engineer  coordinates  the  T&E  planning  with 
the  Program  Office,  ITT.  stakeholders,  test  community  as  appropriate  and  ensures  plaimnig  consistency  with 
the  other  functional  and  acquisition  plans  (i.e.  SEP,  EMP,  LCMP.  LCSP). 

The  T&E  Engineer  provides  Ml  support  to  define  the  program  and  technical  objectives  where  T&E  related 
challenges  and  risks  are  known  or  anticipated.  The  T&E  Engmeer  assists  to  establish  the  business  model, 
develop  program  planning  and  schedules,  and  define  and  implement  program  processes.  Execution  of  the  T&E 
planning  is  typically  defined  through  ail  Operating  Instruction  which  implements  SMC  and  higher  level 
instructions,  policies,  and  directives.  The  PMP  Engineer  ensures  the  T&E  components  of  the  program  are 
appropriately  represented  in  the  program  plans,  program  schedules,  work  breakdown  schedules,  cost  estimates. 
The  T&E  Engineer  also  reports  their  technical  performance  and  progress.  The  T&E  Engineer  shares  in  the  risk 
management  responsibilities  to  identify,  assess,  and  propose  mitigating  actions  of  T&E  related  risks.  They  also 
support  the  Program  Manager's  problem  identification,  resolution,  and  decision-making  processes.  The  T&E 
Engmeer  assists  the  PM  and  the  operational  test  organization  to  prepare,  coordmates,  and  implements  the  ITT 
charter. 

The  T&E  Engineer  contributes  to  the  development  of  the  program  management  products  identified  hi  the 
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Appendix  B  -  Software  Engineering 

Software  engineering  is  an  engineering  discipline  with  a  focus  oil  aO  aspects  of  software,  which  includes 
software  development,  design,  production,  verification,  operation  and  maintenance  It  is  the  application  of  a 
systemic,  quantifiable  and  disciplined  approach  to  analyzing,  designing,  assessing,  implementing,  testing, 
maintaining  and  developing  software.  Software  is  a  wTell -defined  and  established  SMC  Specialty  Engineering 
Discipline  (SED).  and  is  an  integral  element  of  all  space  and  missile  systems  today.  At  SMC,  there  are 
instructions,  guidance,  and  SMC  Staff  resources  available  to  assist  the  Program  Office  Software  Engineer  to 
stand-up  and  execute  essential  software  acquisition  engineering  activities  and  to  hup  lenient  Software 
Engineering  mandates  and  best  practices. 


The  Software  Engineer  plans  and  executes  the  essential  software  engineering  and  management  efforts  in  an 
integrated  and  effective  maimer  to  ensure  that  each  Software  SED  contribution  is  timely,  adequate,  consistent, 
and  compliant.  Software  is  an  integral  part  of  the  overall  systems  planning  and  design.  The  Software  Engineer 
POC  ensures  that  the  software  engineering  contributions  are  chaiuieled  tJuough  the  Systems  Engineering 
Analyses  and  Control  activity. 


Applicable  governance,  standards,  and  guidance 

Policy,  directives,  and  instructions  that  mandate  SMC  software  engineering  related  program  requirements  are 
included  in  a  wide  range  of  mandates  including  those  providing  requirements  for  acquisition.  Systems 
Engineering,  Test  and  Evaluation  (T&E),  Human  Systems  Integration  (HSI),  Systems  Safely,  and  others. 
Table  4  below  identifies  the  significant  governance,  standards,  and  guidance  that  require  SMC  compliance  for 
Software  Engineering. 

Table  4  Governance,  standards,  and  guidance  that  shape  the  Software  Engineering  discipline 


Document  No 

Governance  Title 

Issue 

DoD!  5000  02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  008 

OoDD  8500.01  E 

Information  Assurance  (IA) 

AFI63-101 

Acquisition  and  Sustainment  Life  Cycte  Management 

27  Apr  11 

AFI63-1201 

Life  Cycle  Systems  Engineering 

15  Feb  11 

SMCI 63-103 

Software  Acquisition  Process  Improvement  Instruction 

24  Oct  02 

SMCI 63-104 

Software  Acquisition  Instruction 

21  Nov  05 

SMCI  63-105 

AFSPG  Section  508  Implementation  Policy 

26  Jan  07 

SMCI  63-108 

Software  Acquisition  Management  Plan  (SWAMP) 

9  Feb  11 

SMCI  63-1205 

Space  System  Safety  Policy,  Process  and  Techniques 

20  Aug  07 

Document  No 

Standards  Title 

Issue 

SMC-S-001 

Systems  Engineering  Requirements  And  Products 

12  July  10 

SMC-S-002 

Configuration  Management 

13  Jun  08 

SMC-S-003 

Quality  Assurance  Space  Vehicles  and  Launch  Vehicles 

13  Jun  08 

SMC-S-012 

Software  Development  for  Space  Systems 

13  Jun  08 

SMC-S-021 

Technical  Reviews  &  Audits  for  Systems,  Equip  &  Computer 
Software 

15  Sep  09 

SMC-S-023 

Human  Computer  Interface  Design  Criteria  Volumes  1  &  2 

19  Mar  10 

MIL-STD-1472F 

DoD  Design  Criteria  Standard  for  Human  Engineenng 

23  Aug  99 

MIL-STD-1833 

Test  Requirements  For  Ground  Equipment  And  Associated 
Computer  Software  Supporting  Space  Vehicles 

13  NOV  89 

MIL-STD-882C 

System  Safety  Program  Requirements 

19  Jan  93 
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|  ISQ/IEC 15939  |  Systems  and  software  engineering  -  Measurement  process  |  23  Jul  07  | 


Document  No 

Guidance  Title 

Issue 

AF  TO.  00-5-16 

Technical  Manual  Software  Manager's  Manual 

15  Oct  03 

TOR-20Q4(3909)3405 

Metrics-based  Software  Acquisition  Management. 

May  04 

TOR-2006(8506)-5749 

Mission  Assurance  Tasks  for  Software 

30  Apr  0/ 

TOR-2007(8546)-6018  Rev  A 

Mission  Assurance  Guide 

TOR-201 1(8591  )-10517e 

Software  Review  Assessment  Primer 

EIA/IEEE  Interim  Standard  J- 
STD-016-1995 

Standard  for  Information  Technology,  Software  Life  Cycle 
Processes  Software  Development  Acquirer-Supplier  Agreement 

Sep  95 

IEEE  1044-1993 

Standard  Glassification  for  Software  Anomalies 

Jan  95 

IEEE  Std  610.12-1990 

Glossary  of  Software  Engineering  Terminology 

Sep  90 

CMMI-DEV,  VI  .3 

CM  Ml®  for  Development,  Improving  Processes  for  Developing 
Better  Products  and  Services 

Nov  10 

SMC-G-003 

SMC  CMMI-A  Process  Appraisal  Method  (2009} 

DAG,  Chapter  4.4.16 

Software 

14  Oct  04 

SAG 

Software  Acquisition  Guidebook  (interim) 

htto :  W  www .  d  ro  iectoffi  ce  r.  ora/S  AG/s  w  index.htm 

SMC  Clinger-Cohen  Act  (CCA)  Compliance  Guidebook 

DoDI  5000.02  establishes  requirements  for  software  design  progression  as  an  element  of  Integrated  System 
Design  to  include  technical  design  reviews  and  post-design  review  assessments.  This  Instruction  also  requires  a 
Software  Re  so  urc  es  Data  Report  (SRDR)  for  all  major  contracts  and  subcontracts  for  contractors 
d  eve  lop  icg/pr  o  due  ing  software  elements  witlim  acquisition  category  (AC  AT)  I  and  IA  programs  and  pre- 
Major  Defense  Acquisition  Program  (MDAP)  and  pre-Major  Automated  Infomiation  System  (MAIS) 
programs  subsequent  to  Milestone  A  approval  for  any  software  development  element  with  a  projected  software 
effort  greater-  than  S20M. 

DoDD  8500.0 IE  applies  to  weapons  systems 
software,  that  is  physically  part  of,  dedicated  to, 
or  essential  to  a  platform's  mission  performance 
where  there  is  a  platform  Information 
Technology  (IT)  interconnection. 


At  SMC,  the  Software  Engineering  discipline 
conforms  to  SMC 1  s  Software  Development  for 
Space  System,  SMC-S-012.  This  standard 
provides  requirements  and  expectations  for 
contractor  software  development  activities.  It 
applies  to  the  development  of  systems  that 
contain  software  (e.g.,  hardware- software 
systems,  software-only  systems,  and  stand-alone 
software  products).  It  is  also  relevant  to 
government  in-house  agencies,  contractors,  or 
subcontractors  performing  software 
development.  The  SMC  Software  Acquisition 
Instruction  SMCI  63-104  provides  requirements 
for  software-intensive  program  acquisitions  to  ensure  successful  acquisition  of  software-intensive  systems. 
Tills  instruction  identifies  activities  and  processes  that  must  be  followed.  From  a  safety  aspect,  the  Software 


Date  Item  Title 

Date  Item 
Description 

Software  Development  Ptan  (SDP) 

SMC-S-012  Appendix  H 

Software  Test  Plan  (STP) 

DI-IPSC-81438A 

Software  Installation  Ran  (SIP) 

DI-IPSC-81428A 

Software  Transition  Ptan  (STrP) 

DI-IPSC-81429A 

Interface  Requirements  Specification  (IRS) 

DI-IPSC-81434A 

System/Segment  Design  Descnpfion  (SSDD) 

DI-IPSC-81432A 

Interface  Design  Description  (IDD) 

DI-IPSC-81436A 

Software  Requirements  Specification  (SRS) 

DI-IPSC-81433A 

Software  Design  Description  (SDD) 

DI-IPSC-81435A 

Database  Design  Description  (DBDD) 

DI-IPSC-81437A 

Software  Test  Description  (STD) 

DI-IPSC-81439A 

Software  Test  Report  (STR) 

Dl  -  IPS  C-8 1 440 A 

Software  Product  Specification  (SPS) 

DI-IPSC-81441A 

Software  Version  Description  (SVD) 

DI-IPSC-81442A 

Software  User  Manual  (SUM) 

Dl- IPS  C-8 1443 A 

Computer  Operation  Manual  (COM) 

DI-IPSC-81446A 

Computer  Programming  Manual  (CPM) 

DI-IPSC-81447A 

Firmware  Support  Manual  (FSM) 

DI-IPSC-81448A 
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Engineering  discipline  is  also  subject  to  the  Space  System  Safety  Policy  Process  and  Techniques,  SMCI  63- 
1205  and  the  MIL-STD-S82C  System  Safety  Program  Requirements  standard  at  SMC.  This  standard  specifies 
a  list  of  DID s  that  are  required  as  contract  deliverables  which  are  exhibited  in  the  table  below.  SMCI  63-104 
also  provides  a  list  of  life  cycle  milestone  reviews  for  the  DID's  and  their  software  development  products  for 
which  CDRLs  should  be  considered. 

Software  Engineers'  Contributions  to  Acquisition  Life  Cycle  Framework 

The  DoD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  The  Software  Engineers'  contributions  over  tliis 
life  cycle  are  best  represented  within  the  phase  of  acquisition.  Figure  5  below  provides  die  acquisition  life 
cycle  Fame  work  within  which  Software  Engineers  perform  as  well  as  the  products  that  the  Software  Engineers 
develop  or  contribute  to  their  development.  This  figure  along  with  SMCI  63-104,  Software  Acquisition 
Instruction,  summarizes  the  requirements  to  perform  software  engineering  planning,  supports  pre-  and  post- 
contract  award  acquisition  activities,  and  performs  software  engineering  and  management  across  the  system 
lifecycle.  SMC  Program  Offices  establish  and  implement  software  engineering  program  strategies  and 
objectives  consistent  with  the  tenets  of  appropriate  policies,  SMC  acquisition  objectives,  and  program 
objectives.  The  directorate  or  the  Program  Office  prepares  an  initial  Software  Acquisition  Management  Plan 
(SWAMP)  at  the  MDD  activity  for  MDA  approval.  The  final  SWAMP  is  then  updated  prior  to  the 
performance  of  the  System  Functional  Review  (SFR).  The  Progr  am  Office  develops,  attains  approval  for,  and 
incorporates  software  engineering  planning  into  the  Systems  Engineering  Plan  (SEP)  and  higher  level 
integrated  planning  (e.g.,  IMP)  in  accordance  with  current  DoD  policy.  Tliis  planning  is  firmly  based  on 
program  and  technical  objectives,  strategies,  DoD  mandates,  and  instructions. 

An  effective  software  engineering  program  supports  all  of  the  major  acquisition  activities  throughout  the  full 
system  life  cycle.  The  Software  Engineer  sufficiently  defines  the  software  engineering  program  planning  to 
achieve  the  software  engineering  and  overall  program  objectives  and  requirements.  The  planning  specifies 
tasks  and  functions  to  be  performed,  timing  of  tasks,  resources  required,  and  products  to  be  developed.  The 
software  engineering  planning  are  then  reflected  appropriately  in  the  WBS,  IMP,  IMS,  and  other  program 
documents  that  address  software  engineering  related  elements.  The  Software  Engineer  delineates  the  program 
office  strategy  for  integrating  software  into  the  systems  engineering  process  and  describes  the  software 
management  approach  in  the  SWAMP.  The  software  engineering  planning  is  executed  concurrently  with  the 
Program  Office  Operating  Instruction  that  documents  the  process  to  perform,  control,  and  integrate  ail  software 
engineering  and  management  activities  for  each  phase  of  acquisition. 

The  SMC  Program  Office  software  engineering  planning  (usually  contained  in  the  SWAMP,  SEP,  IMP)  and 
the  processes  delineated  in  the  OI  are  also  based  upon  the  appropriate  program-approved  life  cycle.  The 
following  subsections  delineate  software  engineering  contributions  to  acquisition  activities  and  products  by 
DOD  acquisition  Phase.  Refer  to  SMCI  63-104  for  a  more  complete  list  of  software  engineering  activities  and 
products  that  are  prepared  by  the  Program  office  and  their-  Contractors. 

1*  Materiel  Solution  Analysis,  During  this  phase  the 
Software  Engineer  provides  inputs  to  and  supports  most 
program  acquisition  activities  to  include  the  development 
of  the  acquisition  strategy,  inputs  to  the  cost  estimates, 
solicitation, fReqnest  for  Proposal  (REP)  development  for 
Contractor  studies,  and  proposal  evaluation  activities. 


MSA  Phase  —  SMC  Acquisition  Products 


PMD;  ASP,  TPS,  DM5,  TES _ 

Software  Cost  Estimate _ 

RFP  inputs  (software  requirements;  assessment 
requirements;  High  level  software  concepts _ 

APB,  CCA,  SEP,  LCMP,  draft  SWAMP 
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The  Software  Engineer  also  contributes  to  the  development  of  the  MSA  Phase  acquisition  products. 

2.  Technology  Development.  The  Software  Engineer  provides  inputs  to  and  supports  all  program 
acquisition  activities  to  include  the  development  of  the 
acquisition  strategy,  updates  to  the  software  cost 
estimate  and  development  of  the  Cost  Analysis 
Requirements  Description  (CARD),  solicitation/REP 
development  and  proposal  evaluation  activities.  The 
Software  Engineer  is  key  to  the  solicitation/RFP 
development  and  proposal  evaluation  in  addition  to 
identifying  the  software  related  contract  requirements, 
software  tasks,  test  and  demonstration  requirements  to  meet  software  engineering  objectives.  The  Software 
Engineer  also  contributes  to  the  development  and  updates  to  the  TD  Phase  acquisition  products.  At  TD 
Phase,  software  design  evolves  and  is  established  at  the  allocated  baseline  level  and  architecturally 
documented  to  reflect  a  system  level  maturity  commensurate  for  a  successful  PDR. 

3.  Engineering  &  Manufacturing  Development*  The 

Software  Engineer  provides  inputs  to  and  supports  all 
program  acquisition  activities  to  include  updates  to  the 
acquisition  strategy  and  updates  to  the  software  cost 
estimate  to  reflect  the  actual  teclmical  solutions 
determined  and  updates  to  the  CARD.  The  Software 
Engineer  supports  the  solicitation/REP  development  and 
proposal  evaluation  activities  winch  include  providing  the 
teclmical  inputs  including  technical  requirements, 
compliance  standards,  engineering  approaches, 
incentives,  and  warranty  programs  to  meet  program  objectives.  The  Software  Engineer  identifies  other 
contract  requirements  as  necessary  to  meet  software  engineering  objectives  and  also  contributes  to  the 
development  and  updates  to  the  EMD  Phase  acquisition  products. 

Dining  tliis  phase.  Software  Engineering  efforts  are  concentrated  on  evolving  and  assessing  the  software 
design  to  assure  that  1)  the  software  design,  including  logic,  algoritlnn,  architectural  artifacts,  etc,  is 
evolving  consistent  with  the  baselined  requirements  and  trade  decisions.  2)  software  design  qualification  is 
progressing  consistent  with  the  contract  requirements,  and  3)  the  software  will  conform  to  regulatory 
requirements. 

The  Software  Engineer  supports  the  dev  elopment  of  the  acquisition,  technology  demonstration,  and  test 
strategies  to  ensure  successful  implementation  of  software  capabilities.  The  Software  Engineer  supports 
the  definition  of  contract  requirements  such  as  Software  performance  work  statements  and  specification 
requirements,  and  detailed  design  specification  requirements  associated  with  software  performance, 
development,  and  qualification  to  meet  the  system  or  enterprise  level  requirements  and  capabilities.  The 
Software  Engineer  also  supports  the  definition  of  incentives  progr  ams.  T&E.  RAM  requirements. 


EMD  Phase  -  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  QMS _ 

Software  Cost  Estimate;  CARD  update _ 

RFP:  Software  objectives  in  the  S00;  Software 
refated  tasks  in  SOW,  Software  data  products  in 
CDRLs;  SMC-  Software  Engineering  standards  - 
tailored _ 

APB:  baseline  software  cost,  risks,  and  performance 

Software  planning  (SWAMP,  SDR),  SEP,  LCMP 

Software  verification  TEMP  updates 


TD  Phase  -  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS _ 

Software  Cost  Estimate  Update  /  CARD  Development 
RFP:  SDR  objectives  in  the  S00;  software  related  tasks 
in  SOW,  Software  data  products  in  CDRLs;  SMC- 
Sofiware  standards  -  tailored _ 

APB:  baseline  software  cost,  risks,  and  performance 
Software  planning  e.g.r  (SWAMP),  SEP,  ICMP _ 

Software  verification  TEMP  updates 
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Figure  5  Acquisition  life  cycle  process  for  SMC  Software  Development 
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4.  Production  &  Deployment,  Operations  &  Support, 

The  Software  Engineer  provides  inputs  to  and  supports  ail 
program  acquisition  activities  to  include  updates  to  the 
acquisition  strategy  and  updates  to  the  software  cost 
estimate  to  reflect  the  actual  technical  solutions 
determined  and  updates  to  the  CARD.  The  Software 
Engineer  supports  the  solicitation/' REP  development  and 
proposal  evaluation  activities.  The  Software  Engineer 
identifies  other  contract  requirements:  production  and  field  test  Sc  demo  requirements:  field  performance 
and  sustainment  analyses  to  meet  Software  Engineering  objectives. 

Software  Engineers'  Contributions  to  Engineering  Life  Cycle  Framework 

Relationship  to  the  SE  Organization 

The  Software  Engineer  plans  and  executes  the  essential  software  engineering  and  engineering  management 
efforts  in  an  integrated  and  effective  manner  within  the  context  and  full  support  of  the  overarching  Systems 
Engineering  function  and  current  software  related  governance.  The  Software  Engineer  ensures  that  their  SED 
contributions  are  timely,  adequate,  consistent,  and  compliant.  The  Software  Engineer  ensures  that  their 
contributions  are  channeled  tluough  the  Systems  Engineering  Analyses  and  Control  activity. 

Systems  Engineers  manage  the  engineering  process  and  activities  depicted  in  Figure  3  while  the  Software 
Engineer  contributes  to  this  process.  Software  Engineers  support  concept  Sc  architecture  development  and 
analyses:  Modeling  and  Simulation  (M&S)  efforts:  technology  studies  with  potentially  impacted  software 
challenges.  They  also  participate  in  technical  studies  aud  tecluiical  solutions  trades  when  software  engineering 
is  either  a  factor  or  a  component  of  the  proposed  technical  solution.  They  provide  design  analyses  contributions 
to  mitigate  potential  causes  to  system  level  hazards.  They  assess  and  propose  alternative  mitigating  actions  or 
solutions.  The  Software  Engineer  also  works  closely  with  the  System  Engineers  performing  interface  analyses 
and  functional  analyses  to  leverage  the  required  software  related  analyses.  The  Software  Engineer  also 
supports  the  integration  and  verification  Sc  validation  planning  and  execution. 

In  performing  the  management  and  control  function,  the  Systems  Engineer  effectively  integrates  all 
engineering  functions  tluough  the  full  system  life  cycle.  The  Software  Engineer  ensures  then’  tecluiical 
contribution  to  the  overall  engineering  advances  and  is  appropriately  applied  through  systematic  control, 
collaboration  and  sharing  across  the  organization.  In  addition  the  Software  Engineering  products  are  used  by 
the  other  Specialty  Engineers  to  perforin  their  unique  contributions,  and  are  provided  to  technical  and  program 
management  for  decision  making. 

Relationship  to  other  SEDs 

The  Software  Engineer  SED  relationship  to  other  SEDs  is  summarized  in  Figure  1.  Software  Engineer 
interactions  with  the  other  SEDs  are  critical  to  perform  and  integrate  then-  engineering  contributions  to  the 
system  development  efforts. 

The  Software  Engineer  collaborates  with  the  Systems  Engineer,  Arcliitecture  Engineer,  TScE  Engineer,  and 
Design  Engineer  to  ensure  the  system  architecture  includes  software  related  technology,  physical  and 


P&D  /O&S  Phase  -  SMC  Acquisition 
Products 


Updates  to  ASP,  DMSr  Software  Cost  Estimate,  CARD 
RFP:  Software  objectives  in  the  S00;  Software  related 
tasks  in  SOW,  Software  data  products  in  GDRLs; 
SMC-  Safety  standards  -  taitored _ 

SWAMP _ 

Detailed  Software  planning,  SEP,  LCMP,  updates 
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functional  solutions  that  implement  the  software  performance  requirements  as  well  as  for  built-in  diagnostics, 
test  and  fault  management  requirements  for  real-time  or  periodic  system  integrity  prognostics,  health  and/or 
fault  reporting  and  fault  collections. 

The  Software  Engineer  collaborates  with  the  T&E  Engineer  to  strategize,  plan,  and  execute  the  software 
DT&E  and  OT&E.  The  Software  Engineer  collaborates  with  the  Systems  Engineer  and  the  T&E  Engineer  to 
strategize,  plan,  and  execute  software  prototyping  or  rapid  software  development  to  validate  requirements, 
explore  softw  are  design  alternatives,  and  confirm  performance. 

The  Software  Engineer  supports  the  Reliability  Engineer  in  the  performance  of  the  failure  analyses  to  identify 
software  failure  modes  and  determine  reliability  solutions  that  may  be  partially  adhered  through  application  of 
software  techniques  and  reliability  measurement  technologies. 

Software  Engineers  team  with  the  System  Safety  Engineers  to  perform  software  contribution  to  system  risk 
analyses  and  to  determine  items  or  functions  when  performed  or  whose  failure  could  lead  to  a  hazardous 
system  state  —  one  that  could  result  in  unintended  death,  injury,  loss  of  property,  or  environmental  harm. 
They  also  work  with  Reliability  Engineers  to  improve  the  dependability,  reliability,  maintainability,  and 
availability  of  the  software  products  that  ar  e  designed  and  developed. 

Software  Engineers  work  closely  with  Human  Systems  Integration  to  ensure  systems  are  design  that  can  be 
operated  and  maintained  by  users:  and  are  liabi table  and  safe  with  minimal  software  and  occupational  health 
hazards.  The  Software  Engineer  works  closely  with  the  Logistics  Engineers  to  determine  software  maintenance 
and  maintainability  requirements  and  technical  solutions.  Implementation  of  the  softw  are  related  requirements 
are  initially  conveyed  in  the  maintenance  concept  and  system  architecture.  Software  Engineers  play  an  intricate 
role  with  respect  to  Information  Assurance  and,  in  particular,  to  software  items  or  portions  thereof  whose 
failur  e  could  lead  to  a  breach  of  system  security  or  system  privacy  protection. 

Interactions  among  the  Software  Engineer  and  the  other  disciplines  are  extensive.  Refer  to  the  SMC  Softw  are 
instructions  and  guidance  Table  4  for  more  detailed  discussion  of  these  interactions. 

Tools  Selection  and  Use 

The  Software  Engineer  considers 
effectiveness  and  efficiencies  gained  by 
selecting  and  using  the  best  choice  of 
Software  Engineering  tools. 


Typical  Software  Engineering  Functions  Requiring  Tools 


Software  Development  Planning _ 

Software  Development  Implementation _ 

Software  Development _ 

Software  Configuration  Management _ 

Software  Modeling  and  Architecture  Development _ 

Software  Testing _ 

Software  Improvements/Enhancements  (e.g.  CMMt,  ISO  90QQ;  IS0  15504) 

Software  Cost  Estimating 


Engineering  Activities  and  Products  over  the  Life  Cycle 

Engineering  activities  that  are  prevalent  in  software  engineering  include: 

Note:  tlris  is  not  intended  to  be  an  all-inclusive  list  of  activities.  Each  Software  Engineer  must  scope  their 
programs  to  determine  their  required  software  engineering  activities. 
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•  Early  in  the  life  cycle,  identify  software  technology  challenges. 

•  Support  concept  and  architectural  development;  provide  software  related  factors  into  concept  and 
architectural  trades. 

•  Contribute  to  identify  all  software  components  of  each  proposed  concept,  architecture,  and  design 
solution  to  include  operational/ mission  software:  engineering  software  to  perform  modeling  and 
simulations,  test,  and  analyses;  training  software;  production,  integration;  deployment,  and 
sustainment  software. 

•  Assist  hi  the  conceptualization  and  realization  of  net-centric  migration  when  SMC  Program  undergoes 
major  modifications. 

•  Assist  in  the  conceptualization  and  realization  of  information  assurance  and  system  security  as  they 
relate  to  software  solutions. 

•  Determine  all  applicable  software  related  governance  that  applies  to  the  Program  Office. 

•  Identify,  and  extract  requirements  via  requirements  analysis.  Assess  Contractors1  requirements 
analysis  performance. 

•  Ensure  the  software  design  solution  practices  lead  to  well  documented  rationale  and  are  balanced  with 
all  pertinent  factors,  e.g.,  reliability,  growth  potential,  reusability,  security,  and  other  factors. 

•  Assist  to  define  and  implement  an  effective  measurement  analysis  and  continuous  improvement 
program  to  include  collection  and  analysis  of  software  related  metrics  as  well  as  technical 
performance  measures, 

•  Ensure  Contractor  performance  of  software  quality  engineering  /  quality  assurance 

•  Ensure  Program  Office  and  Contractors  retain  adequate  configuration  control  of  the  evolving  software 
design. 

•  Assist  to  plan,  monitor,  and  assess  software  test  /  V&Y  results  to  ensure  the  system  meets  its  software 
Technical  Performance  Measures  as  an  integral  and  critical  part  of  the  software  development  process 
that  ensures  software  deficiencies  are  revealed  and  resolved  as  early  as  possible. 

Software  Analysis  anti  Impact  Assessment:  A  software  analysis  is  performed  to  determine  the  impact  on  and 
by  each  system  product  and  process  alternative.  Proposed  software -related  tradeoffs  and  analyses  are  presented 
by  the  Software  Engineer  through  the  System  Software  Engineering  process  to  determine  balanced  technical 
solutions.  The  following  subsections  delineate  Software  Engineer  contributions  to  engineering  activities  and 
technical  products  by  DOD  acquisition  phase.  Refer  to  SMCI  63-108  for  a  more  complete  list  of  Software 
Engineering  activities  and  products  prepared  by  the  Program  Office  and  their  Contractors. 

1.  Materiel  Solution  Analysis*  During  this 
phase  the  Software  Engineer  may  provide 
inputs  to  and  support  the  Capabilities  Based 
Assessment  process  and  the  JCIDS  process. 

The  Software  Engineer  evaluates  proposed 
concepts  and  architectures  to  identify  and 
assess  implications  of  software  design  and 
development,  and  to  provide 
recommendations  for  each  alternative.  The 
Software  Engineer  assists  to  define,  refine. 


MSA  Phase  —  Technical  Products  Required 


SMC  Software  Technical 

Products 

S/W  Contributions  to  Other 
Organizations1  Products 

High  level  assessment  proposed 
concepts  &  architectures 

Operational  Concepts 

Software  engineering  inputs  and 
factors  for  concept,  architecture, 
technology  studies,  and  trades 

AoA  Studies 

Software  ReqJts  (draft) 

Initial  Capabilities  Doc  (ICD)  Dev 

Roadmap  and  architectural  inputs 
-  identification  &  mitigations  of 
potential  hazards 

DoDAF  CVs,  OVs 
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and  validate  feasibility  of  software  related  requirements  to  support  Initial  Capabilities  Document  (ICD) 
development  and  possibly  Systems  Requirements  Document  (SRD)  development.  Legacy  program  may 
employed  TRD,  The  Software  Engineer  also  contributes  to  the  development  of  the  MSA  Phase  technical 
products. 

2.  Technology  Development*  Dining  this 
phase  the  Software  Engineer  continues  to 
provide  inputs  to  and  supports  the  JCIDS 
process.  The  Software  Engineer  identifies 
and  assesses  software  related  technology 
challenges  including  algorithm  development, 
software,  computing  techniques,  security 
assurance,  and  other  software  design 
challenges.  The  Software  Engineer  also  supports  all  the  engineering  activities  highlighted  witliin  the  box 
titled  Engineering  Activities  for  System  A  Segment  Dei'elopment  &  Design  Figure  5  to  commence  system 
definition  and  development.  Software  Engineer  develops  and  contributes  to  development  of  the  TD  Phase 
technical  products. 


TD  Phase  —  Technical  Products  Required 


SMC  Software  Technical 

Products 

$/W  Contributions  to  Other 
Organizations  *  Products 

Inputs  to  System  Concepts 

Operational  Concepts 

Factors  for  Studies/  Trades 

Operational  Assessments 

Software  Tech  Reqts,  TRD; 

SRD,  Specifications,  ICDs, 
Standards  Selection/  Tailor 

Capabitities  Development  Doc 
(ODD) 

Software  inputs  to  ISP 

DoDAFCVs,  QVs,  AVs,  SVs, 

3.  Engineering  &  Manufacturing 
Development,  Software  Engineer  continues 
to  provide  inputs  to  and  supports  the  JCIDS 
process.  The  Software  Engineer  supports  all 
the  engineering  activities  highlighted  within 
the  box  titled  Engineering  Activities  for 
Detailed  Design  Figure  5  to  commence 
detailed  systems  definition  and 
development.  The  Software  Engineer 
ensures  a  process  is  in  place  to  report, 
analyze,  and  mitigate  software  development 
issues  during  DT&E.  The  Software  Engineer 
provides  inputs  to  and  supports  the  JCIDS  process. 


EMD  Phase  -  Technical  Products  Required 


SMC  Software  Technical 

Products 

S/W  Contii  buttons  to  Other 
Organiza  lions ?  Prod  nets 

Update  System  Concept 

Operational  Concepts 

Technical  Studies/  Trades 

Operational  Assessments 

System  Tech  Req’ts,  TRD,  SRD, 
Spec,  ICDs,  Software  reqJts  flow- 
down  /  allocations 

Capabilities  Production  Doc 
(CPD) 

inputs  to  system  design, 
production,  fielding,  sustain  docs 

DoDAF  Data  and  Products 

Software  Eng  inputs  to  ISP 

Software  evaluations  of  Tech 
Orders,  operations  manuals 

Test,  Demo  reports 

Refer  to  SMCI  63-104,  Software  Acquisition  Process  for  Software  Engineer  activities  and  products 
typically  required  dming  each  phase.  The  Software  Engineer  develops  and  contributes  to  the  development 
of  the  EMD  Phase  technical  products. 
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4*  Production  &  Deployment,  Operations  & 

Support*  The  Software  Engineer  continues 
to  ensure  software  meets  the  contractual 
software  development  requirements,  and 
integration  activities,  and  is  under 
configuration  control.  The  Software 
Engineer  continues  to  identify,  assess,  and 
resolve  software  related  risks  and  issues  as 
they  arise.  The  Software  Engineer  develops 
and  contributes  to  the  development  of  the 
Production  Sc  G&S  Phase  technical  products. 


P&D  !  O&S  Phase  -  Technical  Products  Required 


SMC  Software  Technical 

Products 

S/W  Cod trihn  tions  to  Ollier 
Organizations  *  Produc  ts 

Inputs  tech  baseline  engineering 
changes 

Supportability  assessment  Rpt 
Contribution 

Analyze  reports  of  failures  and 
mishap  incidents 

Operational  Assessments 

Contributions 

T&E  /  Demo,  Reports 

Transition  &  Fielding  Docs 

Software  evaluations  of  tech 
baseline  does,  tech  orders, 
operations  manuals 

Software  Engineers’  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  their  business  model  and  approach  structure  based  primarily  on  their  program 
objectives,  program  and  technical  challenges,  organizational  structure,  as  well  as  program  and  engineering 
planning,  for  example  SWAMP,  SEP,  LCMP.  Software  Engineer  also  supports  Integrated  Baseline  Review 
(IBR). 

The  Software  Engineer  develops  and  implements  the  software  engineering  program  planning  to  achieve 
Program  Office  software  engineering  objectives  and  requirements.  The  planning  should  scope  the  software 
program  to  define  key  tasks  and  functions  to  be  performed  and  products  to  be  developed:  timing  of  tasks,  task 
outputs,  resources  (skills,  tools,  equipment,  and  completion  criteria).  The  Softw- are  Engineer  plans  tasks  to 
integrate  software  development  activities  within  the  Program  Office,  between  Contractors  and  stakeholders. 
The  Software  Engineer  plans  the  tasks  to  establish  and  manage  software  production:  conduct  review  forums ; 
support  Systems  Engineering  and  Integration  (SE&I)  activities,  risk  management,  integration,  and  system 
modifications:  coordinate  die  software  engineering  planning  with  SMC  Staff  Software  Engineering  office, 
integrate  software  engineering  planning  with  other  functional  and  acquisition  plans  (i,e.  SWAMP,  SEP,  ASP, 
LCMP). 

Execution  of  the  Software  Engineer  planning  is  typically  defined  through  a  program  office  Operating 
Instruction  which  implements  SMC  and  higher  level  instructions,  policies,  and  directives.  The  Software 
Engineer  provides  full  support  to  define  the  program  and  technical  objectives  where  software  challenges  and 
risks  are  known  or  anticipated.  The  Software  Engineer  assists  to  establish  the  business  model,  develop  program 
planning  and  schedules,  and  define  and  implement  program  processes.  The  Software  Engineer  ensures  the 
software  components  of  the  program  are  appropriately  represented  in  the  program  plans,  program  schedules, 
work  breakdown  schedules,  cost  estimates.  The  Software  Engineer  also  reports  then  te clinical  performance  and 
progress.  The  Software  Engineer  shares  in  the  risk  management  responsibilities  to  identify,  assess,  and  propose 
mitigating  actions  of  software  related  risks.  They  also  support  the  program  manager's  problem  identification, 
resolution,  and  decision-making  processes. 


Software 
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The  Software  Engineer  contributes  to  the 
development  of  the  program  management  products 
identified  in  the  Table, 


SMC  Program  Management  Products 


PMD 


SWAMP,  SEP,  IMP,  IMS,  WBS 


Decision-making  &  problem  solving  inputs 


Technical  progression  and  issues  reporting 


Software  Cost  Estimate,  CARDs 


Earned  Value  Management  (EVM) 


Processes  (Qls) 


Risk  Management  inputs 
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Appendix  C  -  Integrated  Logistics  Support 

DoDD  5000.01  requires  Program  Managers  to:  "develop  and  implement  performance-based  logistics  strategies 
that  optimize  total  system  availability  while  minimizing  cost  and  logistics  footprint."  Further,  within  the 
Defense  Acquisition  Management  System,  DoDD  5000.01  requires  that:  "Planning  for  Operation  and  Support 
and  the  estimation  of  total  ownership  costs  shall  begin  as  early  as  possible.  Supportability,  a  key  component  of 
performance,  shall  be  considered  throughout  the  system  life  cycle. " 

The  PM,  as  the  life-cycle  manager,  is  responsible  for  accomplishing  program  objectives  across  the  life  cycle, 
including  the  operating  &  support  (O&S)  phase.  Employing  performance -based  life -cycle  product  support  tied 
to  sustainment  metrics  is  the  overarching  Department  of  Defense  (DoD)  concept  for  providing  materiel 
readiness  to  the  User,  the  Program  Manager  (PM),  Product  Support  Manager  (PSM)  and  Life-Cycle 
Logisticians  can  influence  the  design  and  provide  effective,  timely  product  support  capability  to  adiieve  the 
system's  materiel  readiness  and  sustain  operational  capability.  This  can  be  effected  by  placing  the  emphasis  on 
integrating  life-cycle  management  principles,  using  performance  -  based  life-cycle  product  support  strategies, 
combining  Systems  Engineering  processes  resulting  hi  materiel  readiness  at  optimal  life-cycle  cost  (LCC) 
through  reduction  of  frequency,  duration,  and  related  costs  of  availability  degrading  events,  reducing  the 
system's  manpower  and  logistics  footprint. 

The  SMC  Program  Office  Logistician  plans  and  executes  the  essential  Logistics  Engineering,  acquisition,  and 
management  efforts  hi  an  integrated  and  effective  manner  to  ensure  that  each  Integrated  Logistics  Support 
(ILS)  contribution  is  timely,  adequate,  consistent,  and  compliant.  The  Logistician  ensures  that  then  engineering 
contributions  are  channeled  through  the  Systems  Engineering  Analyses  and  Control  activity.  The  Logistician 
also  supports  the  Program  Office  engineering  analysis  and  control  efforts  as  well  as  technical  and  program 
management  decision  making. 

Applicable  Governance,  Standards,  and  Guidance 

Policy,  directives,  and  instructions  that  mandate  ILS  related  program  requirements  are  included  in  a  wide  range 
of  mandates  including  those  providing  requirements  for  acquisition,  reh ability  and  maintainability.  T&E. 
software.  Systems  Engineering,  and  others.  Table  5  below  identifies  the  significant  governance,  standards,  and 
guidance  which  generally  require  SMC  compliance  with  ILS  requirements  and  objectives. 


Table  5  Governance,  standards,  and  guidance  that  shape  I  he  Integrated  Logistics  Support  Engineering  discipline 


Document  No 

Governance  Title 

Issue 

DoDI  5000.01 

The  Defense  Acquisition  System 

20  Nov  07 

OoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

CJCSI 3170  01G 

Joint  Capabilities  Integration  and  Development  system 

01  Mar  09 

DoD!  3020.37 

Continuation  of  Essential  DoD  Contractor  Services  During  Crises 

26  Jan  96 

DoDI  4151.19 

Serialized  Item  Management  (SIM)  for  Materiel  Maintenance 

26  Dec  06 

DoDI  4151.20 

Depot  Maintenance  Core  Capabilities  Determination  Process 

05  Jan  07 

DoDI  4151.22 

Condition  Based  Maintenance  Plus  (CBM+)  for  Materiel 

Maintenance 

02  Dec  07 

DoDI  5000.67 

Prevention  &  Mitigation  of  Corrosion  on  DoD  Military  Equipment  & 
Infrastructure 

01  Feb  10 
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DoDI  5200.39 

Critical  Program  Information  (CPI)  Protection  Within  the 

Department  of  Defense 

16  Jul  08 

DoDI  8320.04 

Item  Unique  Identification  (1UID)  Standards  for  Tangible  Personal 
Property 

16  JunOB 

DoDD  2010.9 

Acquisition  &  Cross-Servrdnq  Agreements 

24  Nov  03 

DoDD  4140.1 

Supply  Chain  Materiel  Management  Policy 

22  Apr  04 

DoDD  4151.18 

Maintenance  of  Military  Materiel. 

31  Mar  04 

AF1 10-604 

Capabilities  Based  Planning 

10  May  06 

AFi  21-133(1) 

Joint  Depot  Maintenance  (JDM)  Program 

31  Mar  99 

AFI 21-108 

Maintenance  Management  of  Space  Systems 

25  Jul  94 

AFI  21-1 18 

Improving  Air  and  Space  Equipment  RAM 

02  Oct  03 

AFI  63-1201 

Life  Cycle  Systems  Engineering 

23  Jul  07 

AFSPG1 10-604 

Space  Operations  Weapon  System  Management 

01  Oct  07 

AFSPC1 10-1204 

Satellite  Operations 

01  Jun  06 

SMCI 62-001 

Reliability  And  Maintainability 

11  Apr  07 

Document  No 

Standards  Title 

Issue 

MIE-PRF-49506 

Logistics  Management  Information 

11  Nov  96 

MIL-STD-1367-A 

Packing,  Handling,  Storage  &  Transportability  Program  Reqmts  for 
Systems  &  Equpments 

2  Oct  89 

MIL-STD-2073-1 E 

Standard  Practice  for  Military  Packaging 

23  May  08 

TM-86-01TF,  Rev  M 

AF  Technical  Manual  Contract  Reqmts  (TIMOR) 

01  Auq  06 

MIL-PRF-29612B 

Training  Data  Products 

31  Aug  01 

MIL-STD-130N 

Identification  Marking  of  US  Military  Property 

17  Dec  07 

Document  No 

Guidance  Title 

Issue 

DoDR  4140.1-R 

DoD  Supply  Chain  Materiel  Management 

23  May  03 

DoDR  4500.9-R 

Defense  Transportation  Regulation,  Part  2  Cargo 

07  Apr  10 

DoDR  4500.9-R 

Defense  Transportation  Regulation,  Part  3  Mobility 

28  Jan  10 

SAEJA1011 

Evaluation  Cnteria  -  Reliability-Centered  Maintenance  (ROM) 
Processes 

01  Auq  09 

SAEJA1012 

A  Guide  to  the  Reliability-Centered  Maintenance  (RCM)  Standard 

01  Jan  02 

DoDM  5000.4 

DoD  Cost  Analysis  Guidance  &  Procedures 

11  Dec  92 

DoDM  5100.76-M 

Safeguarding  Conventional  Arms,  Ammunition,  &  Explosives 
(AA&E) 

20  May  10 

DoDM4160.21-M-1 

Defense  Demilitanzation  Manual 

15  Feb  95 

DAU  DAG 

Defense  Acquisition  Guidebook,  Chapter  5,  Life-Cycle  Logistics 

MIL-P-24534A 

Specification:  Planned  Maintenance  System 

21  Mar  91 

Suppoitability  Guide 

A  Guide  to  Increased  Reliability  &  Reduced  Logistics  Footprint 

24  Oct  03 

CPATS 

Critical  Process  Assessment  Tool  -  Logistics 

14  Aug  98 

ILS  Logisticians'  Contributions  to  the  Acquisition  Life  Cycle  Framework 

The  DoD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  ILS  contributions  over  this  life  cycle  are  best 
represented  within  the  phases  of  the  Defense  Acquisition  Management  System.  Figure  6  provides  the 
acquisition  life  cycle  framework  within  which  Logisticians  perform  as  well  as  the  products  that  the 
Logisticians  must  develop  or  contribute  to  their  development.  SMC  Program  Offices  establish  and  implement 
ILS  program  strategies  and  objectives  consistent  with  the  tenets  of  appropriate  policies,  SMC  acquisition 
objectives,  and  program  objectives. 

The  Program  Office  then  develops,  attains  approval  for.  and  implements  ILS  planning  through  a  Life  Cycle 
Management  Plan  (LCMP),  the  Systems  Engineer ing  Plan  (SEP)  and  higher  level  integrated  planning  (e.g., 
IMP)  in  accordance  with  current  DoD  policy.  This  planning  will  be  firmly  based  on  program  and  technical 


5  4  SMC  Sped  a  /  rv  Ehgfo # err  rcg  D/a  dpi  i  ?  jes  1LS 

objectives,  strategies.  DoD  mandates,  and  instructions.  In  addition  the  Logistics  Engineer/L ogistician prepares 
the  Transition  Support  Plan  (TSP)  to  establish  planning  and  implementation  requirements  associated  with  the 
production  contracts  fiom  the  Developing  Agency  to  the  Using  Agency.  The  Logistics  POC  also  collaborates 
on  the  TOA  (developed  by  A 5  Turnover  Agreement  (TOA)  to  assist  the  Program  Office  to  prepare  for  all  the 
events  and  documentation  needed  for  turnover. 

An  effective  ILS  program  supports  all  of  the  major  acquisition  activities  tluough  the  foil  system  life  cycle. 
Effective  sustaiiunent  begins  with  the  supportabiiity  analysis  to  form  CDD  requirements  for  each 
supportability  parameter  to  be  designed,  developed,  or  procured  as  proven  commercial  teclmology.  It  is  these 
analysis -driven  supportability  parameters,  once  integrated  tluough  Systems  Engineering  with  ail  other 
technical  parameters,  which  drive  deployed  system  operational  availability,  sustainment  effectiveness,  and 
operator  ownership  affordability. 


All  Phases  -  The  Life  Cycle  Logistician  considers  each  ILS  support  element,  defining 

supportability  objectives. 


Maintenance  Planning:  Establishes  and  documents  maintenance  concepts  and  requirements. _ 

Manpower  and  Personnel:  Identifies  personnel  skills,  grades  and  quantity  required  to  support  operation  and  maintenance  of 
system. 

Supply  Support:  Determines  requirements  to  acquire  and  manage  spares  and  repair  parts. _ 

Support  Equipment:  Identifies  all  equipment  required  to  support  operation  and  maintenance  of  the  system. 

Technical  Data:  Ensures  availability  of  scientific  and  technical  information  used  to  support  systems  acquisition,  operations  and 
sustainment. _ 

Training  and  Training  Support:  Determines  requirements  to  acquire  and  support  training  devices  and  conduct  training  of  the 
user  community  {i.e  f  operators,  maintained,  support  personnel,  etc). _ 

Computer  Resources  Support:  Identifies  facilities,  hardware,  software  and  support  tools  to  operate  and  support  embedded 
computer  systems. 

Facilities:  Identify  real  property  required  to  support  system  operations  and  maintenance _ 

Packaging,  Handling,  Storage  and  Transportation:  Identifies  designs  and  methods  to  ensure  the  system  is  preserved, 
packed,  stored,  handled  and  transported  properly. 

Design  Interface:  Documents  relationships  of  logistics-related  design  parameters  to  readiness  and  support  resources 
requirements;  influence  design  for  supportability. 


The  ILS  planning  sufficiently  defines  the  ILS  program  to  achieve  the  ILS  and  overall  program  objectives  and 
requirements;  specifies  tasks  and  functions  to  be  performed,  timing  of  tasks,  resources  required,  and  products 
to  be  developed:  forms  the  basis  for  the  development  of  the  program  ILS  Operating  Instruction  (01).  The  ILS 
planning  is  then  reflected  appropriately  in  the  WBS,  IMS,  and  other  program  documents  that  ad  dies  s  ILS 
related  elements.  The  ILS  planning  is  executed  concurrently  with  the  Pro  .gram  Office  OI  that  documents  the 
process  to  perform,  control,  and  integrate  ail  ILS  engineering  and  management  activities  for  each  phase  of 
acquisition.  The  SMC  Program  Office  ILS  planning  (usually  contained  in  the  LCMP.  SEP  and  the  detailed  ILS 
program  planning)  and  OI  is  based  upon  the  appropriate  program -approved  life  cycle.  SMC  Program  Offices 
appoint  establish  and  implement  ILS  program  strategies  and  objectives  consistent  with  the  tenets  of  appropriate 
policies,  SMC  acquisition  objectives,  and  program  objectives. 
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MSA  Phase  -  SMC  Acquisition  Products 


PMD 


AQA,  ASPr  ICD,  TDS,  DMS,  TES 


LC  Cost  Estimate 


RFP  inputs  (ILS,  Quality,  RAM  mission/operational/ 
system  requirements;  Assessment  requirements.  High 
level  reliability  formulations 


APB,  CCA 


SSP 


SEP,  LCMP 


Draft  CDD,  Initial  Spt  &  Main!  Concepts 


L  Materiel  Solution  Analysis.  During  this  phase  the  ILS 
Engineer  provides  inputs  to  and  supports  most  program 
acquisition  activities  to  include  the  development  of  the 
acquisition  strategy,  inputs  to  the  cost  estimates. 
solicitation/RFP  development  for  Contractor  studies,  and 
proposal  evaluation  activities  The  ILS  Engineer  focus  is 
on  identifying  initial  concept  and  critical  product  support 
capability  requirements.  Affordable  operational 
effectiveness  is  the  overarching  sustainment  objective 
that  should  be  considered  during  the  JCIDS  process.  The 
ILS  Engineer  supports  mission,  operational,  and  system  concept  definition  and  planning  to  mature 
enabling  technologies.  The  conclusion  of  this  phase  produces  the  initial  acquisition  strategy  (including  the 
sustainment  strategy),  a  contractual  document  required  to  continue  into  the  Technology  Development 
Phase  and  includes  initial  support  and  maintenance  concepts,  LCC.  and  manpower  estimates  for  the 
system  concept.  The  ILS  Engineer  also  contributes  to  the  development  of  the  MSA  Phase  acquisition 
products. 

2.  Technology  Development.  The  ILS  Engineer  provides 
inputs  to  and  supports  all  program  acquisition  activities  to 
include  the  development  of  the  acquisition  strategy  and 
development  of  the  Cost  Analysis  Requirements 
Description  (CARD).  solicitation/RFP  development  and 
proposal  evaluation  activities.  The  ILS  Engineer 
identifies  other  contract  requirements  such  as 
incentive  s/ warranty  programs  and  test  &  demo 
requirements  to  meet  ILS  objectives.  The  ILS  Engineer 
also  contributes  to  the  development  and  updates  to  the 
TD  Phase  acquisition  products. 

3.  Eu  gin  eerie  g  &  Manufacturing  Development.  The  ILS 
program  acquisition  activities  to  include  updates  to  the 
acquisition  strategy  and  updates  to  the  CARL).  The  ILS 
Engineer  supports  the  solicitation/RFP  development  and 
proposal  evaluation  activities  wliich  include  providing  the 
teclmical  inputs  including  technical  requirements, 
compliance  standards.  engineering  approaches, 
incentives,  and  warranty  programs  to  meet  program 
objectives.  The  ILS  Engineer  identifies  other  contract 
requirements  such  as  incentive s/ warranty  programs  and 
prototype  and  engineering  qualification  unit  supportability  related  test  &  requirements  to  meet  ILS 
objectives.  The  ILS  Engineer  also  contributes  to  the  development  and  updates  to  the  EMD  Phase 
acquisition  products. 


TD  Phase  -  SMC  Acquisition  Products 

Updates  to  AOAr  ASP,  TDS,  DMS 

LC  Cost  Estimate  Update  /  CARD  Development 

RFP:  ILS  objectives  in  the  S00;  ILS  notated  tasks  in 
SOW,  ILS  data  products  in  CDRLs;  SMC  ILS 
standards  tailored 

SSP:  evaluation  criteria  for  ILS 

APB:  ILS  objectives  &  related  concept  descriptions 

Detailed  ILS  planning,  SEP,  LCMP,  TEMP 

Draft  CDD,  Initial  Spt  &  Maint  Concepts,  Spt  Strateqy 

Sys  Perf  Specs,  PDRr  TEMP,  ISP, 

Core  Log  Analysis/Source  of  Repair  Analysis 

Prelim  Maint  Plans,  Affordability  Assessment 

Engineer  provides  inputs  to  and  supports  all 

EMD  Phase  -  SMC  Acquisition  Products 

Updates  to  APB,  ASP,  ICD,  CDD,  TDS,  DMS 

CARD  update,  PDR,  DT&E  Rpt, 

RFP:  ILS  objectives  in  the  S00;  ILS  related  tasks  in 
SOW,  ILS  data  products  in  CDRLs;  SMC-  ILS 
standards  -  tailored 

SSP:  evaluation  criteria  for  RAM 

APB:  ILS  objectives  &  related  concept  descriptions 

Detailed  ILS  planning,  SEP,  LCMP,  TEMP  updates 

Capability  Production  Doc,  Approved  Maint  Plans 
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Figure  6  Acquisition  life  cycle  process  for  SMC  Logistics  Engineering 
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4*  Production  &  Deployment.  The  ILS  Engineer  provides 
inputs  to  and  supports  all  program  acquisition  activities  to 
include  updates  to  the  acquisition  strategy  and  updates  to 
the  CARD.  The  ILS  Engineer  supports  the 
solicitation/REP  development  and  proposal  evaluation 
activities.  The  ILS  Engineer  identifies  other  contract 
requirements:  incentives/' warranty  programs:  production 
and  field  test  &  demo  requirements:  field  performance  and 

5.  Operations  &  Support.  In  the  total  life-cycle  systems 
management  concept,  providing  user  support  and 
managing  the  demilitarization  and/or  disposal  of  old 
systems  are  the  PM's  responsibilities.  During  this  phase, 
the  PM  is  the  system  local  point  to  the  User.  The  PM  and 
Iii s/her  assigned  ILS  POC  focuses  on  supporting  the  User 
by  executing  the  sustainment  program  arid  on  making 
adjustments  based  on  effectiveness  and  operating 
conditions  using  Systems  Engineering  principles.  The 
ILS  Logistician  consults  with  accountable  military  department  logistics  officials  prior  to  making  depot 
maintenance  source  of  support  decisions  to  ensure  the  DoD  Component  depot  maintenance  50  percent 
limitation  statutory  requirement  is  being  met.  The  PM  and  ILS  Logistician  coordinate  with  DoD 
Component  logistics  activities  and  DLA,  as  appropriate,  to  identify  and  apply  apphcable  demilitarization 
requirements  necessary  to  eliminate  the  functional  or  military  capabilities  of  assets  and  determine  property 
disposal  requirements  for  system  equipment,  support  assets,  and  by-products. 

ILS  Engineers'  Contributions  to  the  Engineering  Life  Cycle  Framework 

Relationship  to  the  SE  Organization 

Systems  Engineers  manage  the  engineering  process  and  activities  depicted  in  Figure  3  while  the  ILS  Engineer 
contributes  to  this  process.  ILS  engineers  support  concept  and  architecture  development  and  analyses: 
mode  hug  and  simulation  efforts;  technology  studies.  The  ILS  engineer  develops/ derives  their  requirements  and 
supports  the  requirements  analyses  and  allocations  process.  They  also  participate  in  tecluiical  studies  and 
technical  solutions  trades  when  logistics  elements  are  a  factor.  They  provide  design  analyses  contributions  to 
determine  and  collaborate  with  the  RAM  Engineer  to  adjust  reliability  allocations,  tip  date  reliability 
predictions,  and  ensure  confidence  in  attaining  ILS  requirements  through  analyses,  demo,  and  test. 

Relationship  to  other  SEDs 

hi  performing  the  management  and  control  function,  the  SE  effectively  integrates  all  engineering  functions 
through  the  full  system  life  cycle.  The  ILS  Engineer  ensures  their  technical  information  is  current  and 
appropriately  applied  through  systematic  control,  collaboration  and  sharing  across  the  organization.  All 
elements  of  ILS  are  developed  hi  concert  with  the  system  engineering  effort  and  with  each  other.  Tradeoffs  are 
required  between  elements  in  order  to  determine  balanced  solutions  and  to  a c quite  a  system  that  is:  affordable 


1  F&D  Phase  -  SMC  Acquisition  Products 

Updates  to  ASP,  TDS,  QMS 

RFP:  ILS  objectives  in  the  SOO;  ILS  related  tasks  in 
SOW,  ILS  data  products  in  CORLs;  SMC  ILS 
standards  tailored 

SSP:  evaluation  criteria  for  RAM 

Detailed  ILS  planning,  SEP,  LCMP,  TEMP  updates 

CARD  update,  RCA  Rptc  Info  Supportability  Cert 

sustainment  analyses  to  meet  ILS  objectives. 

|  O&S  Phase  —  SMC  Acquisition  Products 

Product  Spt  Inteqrator/Provider  performance  Rpt 

Product  improvement  Rpt 

Configuration  Control  Rpt 

Svstem  Supply  Mqt 

LCMP 

Cost/Benefit  Analysis 

Replacement  Planning 

System  Supportability  Assessment 

Disposal  Planning 

ILS  SMC  Specialty  Engineering  Disciplines  5  9 

(lowest  lite  cycle  cost),  operable,  supportable,  sustainable,  transportable,  and  environmentally  sound.  ILS 
develop  mental  efforts  are  typic  ally  categorized  into  the  following  10  elements: 

L  Reliability  Engineering,  Maintainability  Engineering  and  Maintenance  (preventive,  predictive  and 
corrective)  PI  aiming 

2.  Supply  (Spare  part)  Support  (e.g.  AECMA  2000M  standard)  and  acquire  resources 

3.  Support  and  Test  Equipment/Equipment  Support 

4.  Manpower  and  Personnel 

5.  Training  and  Training  Support 

6 .  T  e  clinic  al  Data  /  Public  ations 

7.  Computer  Reso  urces  Support 

8.  Facilities 

9.  Packaging.  Handling,  Storage,  and  Transportation  (PHS&T) 

10.  Design  Interface 

The  logistics  support  analyses  must  be  timed  and  applied  by  the  other  Specialty  Engineers  to  perform  their 
unique  contributions,  and  must  be  provided  to  technical  and  program  management  for  decision  making. 

The  ILS  Engineer  SED's  relationship  to  other  SEDs  is  summarized  in  Figure  1.  The  ILS  Engineer  also  works 
closely  with  the  System  Engineers  performing  deployment,  integration  and  verification  and  validation  planning 
and  execution.  The  Logistics  Engineer  works  closely  with  the  Reliability  Engineer  performing  maintenance 
and  sustainment  analyses.  The  Logistics  Engineer  aligns  closely  with  the  Quality  Assurance  and  Quality 
Engineer  to  ensure  delivery  and  deployment  of  reliable  products  through  controlled  and  predictable  quality 
levels  during  production,  handling,  storage,  packaging,  and  transportation. 


Tools  Selection  &  Use 

The  ILS  Engineer  considers  effectiveness  and 
efficiencies  gained  by  selecting  and  using  the 
best  choice  of  ILS  tools  considering  the  ILS  tool 
requirements  for  LSA,  logistics  database 
development  and  management,  information 
sharing,  automated  data  exchanges  with  other  tools,  and  other  considerations. 

Engineering  Activities  and  Products  over  the  Life  Cycle 

The  following  subsections  summarize  the  ILS  Engineer's  contributions  to  engineering  activities  and  technical 
products  by  DOD  acquisition  phase.  Refer  to  SMC  ILS  guidance  for  detailed  activities,  requirements  and 
guidance. 


ILS  Functions  Requiring  Tools 


Operations  &  Sustainment  Modeling _ 

RAM  Analyses  &  Allocations _ 

Experiment  Design,  Growth,  and  Life  Data  Analysis 

Reliability  Centered  Maintenance _ 

FMEA,  LSA,  LSAR _ 

Training 
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1.  Materiel  Solution  Analysis*  Dining  tills 
phase  the  ILS  Engineer  may  provide  inputs 
to  and  support  the  Capabilities  Based 
Assessment  process  and  the  JCIDS  process. 

The  ILS  Engineer  also  contributes  to  the 
development  of  the  MSA  technical  products. 


ILS 


MSA  Phase  —  Technical  Pro  ducts  Required 


2.  Technology  Development*  During  this 
phase  the  ILS  Engineer  continues  to  provide 
inputs  to  and  supports  the  JCIDS  process. 

The  ILS  Engineer  also  supports  all  the 
engineering  activities  liiglilighted  within  the 
box  titled  Engineering  Activities  for  System 
<£  Segment  Development  A-  Design  Eigure  6 
to  commence  system  definition  and 
development.  ILS  Engineer  develops  and 
contributes  to  development  of  the  TD  Phase  technical  products. 


SMC  ILS  Technical 

Products 

ILS  Contributions  to  Other 
Organizations’  Products 

High  levs]  reliability  analysis 

Operational  Concepts 

ILS  inputs  and  factors  for 
concept,  architecture,  technology 
studies,  and  trades 

AoA  Studies 

System  ILS  Req’ts  (draft) 

Initial  Capabilities  Doc  {[CD)  Dev 

Roadmap  inputs 

DoDAF  CVsf  OVs 

TD  Phase  -  Technical  Products  Required 

SMC  ILS  Technical 
Products 

ILS  Contributions  ro  Other 
Organizations1  Products 

Inputs  to  System  Concepts 

Operational  Concepts 

Factors  for  Studies/  T rades 

Operational  Assessments 

ILS  Tech  Req’ts,  TRD,  SRO, 
Specifications,  ICDs,  Standards 
Selection/  Tailor 

Capabilities  Development  Dec 
{CDD} 

ILS  inputs  to  ISP 

DoDAF  CVs,  OVs 

ILS  Analyses  Rpts 

The  ILS  Engineer  focus  is  on  developing  preliminary  design  (down  to  subsystem'  equipment  level), 
reducing  integration  and  manufacturing  risk,  and,  Horn  a  sustainment  perspective,  optimizing  system 
sustainment  through  designed -in  criteria  to  help  ensure  sustainability,  with  particular  attention  to  reducing 
the  logistics  footprint,  implementing  human  systems  integration,  and  designing  for  support  to  help  ensure 
life -cycle  affordability.  Detailed  plans  for  organizing  to  manage  implementation  of  the  product  support 
package  begin  in  this  phase.  The  support  concept  and  design -to  requirements  to  design  the  product  support 
package  are  defined.  Technology  demonstrations  and  prototyping  are  conducted,  determining  mature, 
affordable  technologies  to  be  included  in  the  system  and  support  system  designs.  The  demonstrations 
results  and  analysis  refine  requirements  and  the  LCC  estimate,  narrow  the  ranges  of  all  program  metrics, 
and  increase  confidence  the  values  can  be  met  at  an  affordable  cost.  ILS  Engineer  emphasis  is  on  maturing 
the  enabling  teclmologies  for  achievement  of  supports bilify  objectives.  Achievable  performance 
evaluations,  given  demonstrated  technologies,  on  refining  supportability  objectives,  and  identifying 
constraints,  system  or  supply  chain,  to  achieve  operational  readiness  or  mission  effectiveness  are 
completed. 
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3.  Engineering  &  Manufacturing 
Development,  ILS  Engineer  continues  to 
provide  inputs  to  and  supports  the  JCIDS 
process.  The  ILS  Engineer  supports  all  the 
engineering  activities  highlighted  within  the 
box  titled  Engineering  Activities  for 
Detailed  Design  Figure  6  to  commence 
detailed  systems  definition  and 
development.  The  ILS  Engineer  along  with 
the  RAM  Engineer  establishes  a  closed -loop 
failure  reporting  system  across  contractors, 
stakeholders  and  other  failure  reporting  analysis  &  corrective  action  contributors.  The  ILS  Engineer  works 
with  the  Reliability  Engineer  to  establish  JRMET  to  assist  in  collecting,  analyzing,  and  categorizing  ILS 
data  dining  DT&E.  The  ILS  Engineer  inputs  to  and  supports  the  JCIDS  process.  ILS  Engineer  develops 
and  contributes  to  the  development  of  the  EMD  Phase  teclmical  products.  In  this  Phase,  the  ILS  Engineer 
focus  is  on  development  of  detailed  integrated  design  to  ensure  producibility  and  operational 
suppo  inability  by  producing  detailed  manufacturing  designs.  Proto  typing  and  analysis  applied  prior  to  tliis 
phase  provides  a  design  based  on  a  mature  technology,  achievable  within  cost,  schedule  and  sustainment 
constraints.  Reduction  of  the  logistics  footprint;  implementing  human  systems  integration;  designing  for 
suppoitability:  and  ensuring  affordability,  integration  with  the  supply  chain,  interoperability,  and  safety 
are  used  to  refine  the  performance -based  support  concept  and  strategy,  with  associated  requirements,  and 
identify  potential  suppoit  providers.  Developing  the  requirements  for  the  long-term  performance- based 
support  concept  and  the  initial  product  support  package  allows  refinement  of  life -cycle  management 
documents  and  analyses  using  iterative  Systems  Engineering  analyses  and  developmental  test  results. 
Critical  sustainment  metrics  are  also  refined  and  incentives  developed  for  eventual  performance-based 
support  contracts  and/or  performance -based  agreements.  Stakeholders  are  identified  and  included  in 
Integrated  Product/Process  Team  (IPT)  processes  to  build  ail  early  understanding  of  and  buy-in  for 
sustainment  requirements  and  objectives.  The  suppoit  concept  is  refined  and  potential  support  providers 
identified.  Incentives  to  design  for  support  and  cost -effectiveness,  are  identified  and  included  in  the 
suppoit  strategy. 


EMD  Phase  —  Technical  Products  Required 


SMC  ILS  Technical 
Products 

ILS  Contributions  to  O  titer 
Organizations-  Products 

Update  System  Concept 

Operational  Concepts 

Technical  Studies/  Trades 

Operational  Assessments 

System  Tech  Reqts,  TRD,  SRD, 
Spec,  ICDs;  RAM  allocations 

Capabilities  Production  Doc 
(CRD) 

Inputs  to  system,  production, 
fielding,  sustain  design  docs 

ILS  inputs  to  ISP 

DoDAF  CVs,  OVs 

RAM  Analyses  Rpts,  RESD, 
models,  predictions 

Test,  Demo  reports 

4.  Production  &  Deployment,  The  ILS 
Engineer  continues  to  provide  inputs  to  and 
supports  the  JCIDS  process.  The  activities  of 
ILS  during  this  phase  are  extensive.  Refer  to 
the  ILS  guidance  for  activities  and  products 
typically  required  during  each  phase.  The 
ILS  Engineer  develops  and  contributes  to  the 
development  of  the  Production  & 

Deployment  Phase  technical  products. 

During  this  phase,  the  ILS  Engineer's 
emphasis  is  on  finalizing  equipment  product  suppoit  packages/  maintenance  plans,  managing  and 
deploying  the  initial  sustainment  capabilities,  and  demonstrating  the  product  support  capabilities  and 
effectiveness.  Once  demonstrated,  fielding  and  implementing  sustainment  capabilities  protide  users  the 


P&D  Phase  —  Technical  Products  Required 


SMC  ELS  Technical 

Products 

ILS  Contributions  to  Other 
Organizations 5  Products 

Inputs  tech  baseline  engineering 
changes 

Suppoitability  Analyses  Rpt 

Analyses  of  production  quality 
reports  and  test  reports 

Operational  Assessments 

Transition  &  Fielding  Docs 

ILS  Analyses  Rpts;  Reliability 

And  Maintainability  Information 
System  Assessments  (REMIS) 

V&V  /  T&E  Reports 
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capabilities  identified  in  requirements  documents.  Measuring  the  product  sustaimnent  package’s 
effectiveness  (including  the  associated  supply  chain)  confirms  user  support  required  to  sustain  the  system 
within  the  budget  provided  is  acliieved,  while  informing  senior  leadership  the  consequences  and  impacts 
on  the  Sustaimnent  KPP/KSAs  of  budget  constraints.  Coord  mating  with  the  contractors,  supply  chain  and 
operators  to  ensure  each  understands  and  is  implementing  responsibilities  in  accordance  with  the  LCMP  in 
an  integrated  fashion.  Monitoring  any  changes  to  the  design,  operational  environment  and  supply  cliain 
and  adjusting  the  logistics  elements  within  the  product  support  package  as  required.  Searching  for 
improvements  to  reduce  the  product  support  package  cost.  Reliability  of  contractor  cost  and  performance 
data  is  verified  by  monitor  mg  contracts. 

5*  Operations  &  Support.  ILS  Engineer 
continues  to  provide  inputs  to  and  supports 
the  JCIDS  process.  The  activities  of  ITS 
during  this  phase  are  extensive.  Refer  to  the 
SMC-G-001  Life  Cycle  Systems 
Engineering,  Section  43.5,  Guide  for  ILS 
Engineer  activities  and  products  typically  required.  The  ILS  Engineer  develops  and  contributes  to  the 
development  of  the  O&S  Phase  technical  products. 

During  the  O&S  Phase,  the  ILS  POC  continually  assesses  the  system  performance  from  the  User's 
perspective  with  existing  reporting  systems  and  user  feedback  to  evaluate  the  fielded  system,  focusing  on 
performance  outcomes  meaningful  to  the  user.  The  data  is  analyzed,  comparing  performance  expectations 
against  actual  performance,  root  causes  of  problems  identified,  and  collective  actions  developed. 
Corrective  actions  are  implemented  through  maintenance  plan/requirement  changes,  process  changes, 
modification  of  performance  -based  product  support  agreements,  and/or  design  changes.  The  final  decision 
for  the  collective  action  selected  will  be  determined  by  a  balance  between  many  factors,  including  but  not 
limited  to  risk/safety,  costs,  schedule,  user  requirements  and  probability  of  success.  The  ILS  engineer 
continues  to  assess  sustainability  effectiveness  of  the  fielded  systems,  adjusting  the  program  as  required  to 
support  the  user.  Users  require  readiness  and  operational  effectiveness  (i.e.,  systems  accomplishing  their 
missions)  according  to  design  parameters  in  an  operational  environment.  Systems,  regardless  of 
application  of  design  for  support  ability,  suffer  varying  stresses  during  actual  deployment  and  use. 
Consequently,  the  PM  should  apply  the  Systems  Engineering  processes  used  in  acquisition  throughout  the 
entire  life  cycle.  The  difference  is  that  dunug  this  phase  actual  use  data  including  user  feedback,  failure 
reports,  and  discrepancy  reports  are  used  instead  of  engineering  estimates.  Wliile  acquisition  phase 
activities  are  important  to  designing  and  implementing  a  successful  and  affordable  sustaimnent  strategy, 
the  ultimate  measure  of  success  is  supporting  the  User  after  the  system  has  been  deployed  for  use. 
Accordingly,  the  PM  and  DoD  Components  conduct  periodic  assessments  of  system  support  outcomes 
comparing  actual  vs.  expected  levels  of  performance  and  support.  Assessments  require  close  coordination 
with  the  user,  snpport  providers  and  appropriate  Systems  Engineering  IPTs.  The  PM  and  ILS  engineer 
conducts  periodic  In-Service  Reviews  which  include  supportability  assessments.  These  assessments  may 
result  in  disposal  of  the  system  folio  whig  statutory  regulations  and  policy. 


O&S  Phase  -  Technical  Products  Required 


SMC  ILS  Technical 
Products 

ILS  Contributions  to  Other 
Organizations’  Products 

Analyses  of  production  quality 
reports  and  test  reports 

Sup  portability  Analyses  Rpt 

Transition  &  Fielding  Docs 

Operational  Assessments 
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ILS  Engineers'  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  then  business  model  and  approach  structure  based  primarily  on  then  program 
objectives,  program  and  technical  challenges,  organizational  structure,  as  well  as  program  and  engineering 
planning  (SEP  plus  detailed  ILS  planning). 

The  ILS  Engineer  develops  and  implements  the  ILS  program  planning  to  achieve  ILS  objectives  and 
requirements.  The  planning  defines  the  ILS  tasks  and  functions  to  be  performed  and  products  to  be  developed: 
timing  of  tasks,  task  outputs,  resources  (skills,  tools,  equipment,  and  completion  criteria.  The  ILS  Engmeer 
plans  tasks  to  integrate  ILS  activities  within  the  program  office,  between  Contractors  and  stakeholders.  The 
ILS  Engineer  plans  the  tasks  to  establish  and  manage  ILS  activities  and  forums;  support  SE&I  activities,  e.g., 
production  process  controls,  V<fcV  activities,  risk  management,  integration,  and  system  modifications; 
Co ord mate  the  ILS  planning  with  SMC  ILS  OPR,  operating  commands,  supporting  commands,  and  test 
agencies:  integr  ate  ILS  planning  with  other  functional  and  acquisition  plans  (i.e.  SEP,  ASP,  LCMP). 

Execution  of  the  ILS  planning  is  typically  defined  through  an  Operating  Instruction.  The  ILS  Engineer 
provides  fiill  support  to  define  the  program  and  technical  objectives  where  ILS  challenges  and  risks  are  known 
or  anticipated.  The  ILS  Engineer  assists  to  establish  the  bushiess  model,  develop  program  planning  and 
schedules,  and  define  and  implement  program  processes.  The  ELS  Engineer  ensures  the  ELS  components  of  the 
program  are  appropriately  represented  in  the  program  plans,  program  schedules,  work  breakdown  schedules, 
cost  estimates.  The  ELS  Engineer  also  reports  then  technical  performance  and  progress.  The  ILS  Engineer 
shares  in  the  risk  management  responsibilities  to  identify,  assess,  and  propose  mitigating  actions  of  ILS  related 
risks.  They  also  support  the  program  manager's  problem  identification,  resolution,  and  decision  making 
processes. 

The  ILS  Engineer  contributes  to  the  development  of  the 
program  management  products  identified.  The  SMC  Systems 
Engineering  Pinner  &  Handbook  describes  the  role -up  and 
relationships  of  the  engineering  detailed  plans  and  schedules, 
and  WBS  as  well  as  the  integration  of  ILS  with  program  and 
project  management.  ILS  develops  and  contributes  to  the 
development  of  the  program  management  products  identified. 


SMC  Program  Management  Products 


SEP,  IMP,  IMS  WBS,  LCMP 


Decision-making  &  problem  solving  inputs 


Technical  progression  and  issues  reporting 


LC  Cost  Estimate  (CARDs),  Processes  (01s) 


Risk  Management  Inputs 
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Appendix  D  -  Design  Engineering 

SMC  Program  Office  Design  Engineers  at  the  system,  segment  and  subsystem  levels  participate  throughout  the 
acquisition  life  cycle  process  to  achieve  higher  innovation,  balanced  solutions,  reduced  system  development 
risks,  apply  reuse  strategies,  and  reduce  cycle  time  and  system  costs.  For  each  of  the  life  cycle  phases  of  Figure 
7,  the  SMC  design  engineer  participates  to  meet  the  objectives  in  planning,  acquisition,  and  engineering 
activities  for  effective  contract  execution. 

The  following  paragraphs  provide  an  overview  of  the  SMC  Project  officer's  design  engineering  roles  and 
responsibility  during  program  execution. 

Design  Integration 

Integrated  System  Design  commences  with  the  entiy  into  the  Engineering  and  Manufacturing  Development 
(EMDj  Phase.  DoDI  5000.02  defines  Integrated  System  Design  as  that  effort  intended  to  define  system  and 
system-o f- systems  functionality  and  interfaces,  complete  hardware  and  software  detailed  design,  and  reduce 
system-level  risk.  Integrated  System  Design  includes  the  establishment  of  the  product  baseline  for  all 
configuration  items.  It  is  commonly  understood  that  SMC  contractors  perform  the  actual  design  of  space  and 
missile  systems  subject  to  cost,  schedule,  and  performance  constraints.  The  SMC  Program  Office  oversees 
contractor  performance  and  participates  in  decisions  on  system  architecture  and  performance.  Design 
implementation  is  achieved  with  concept  documentation,  architectural  artifacts,  system  requirements 
documents  aud  interface  specifications  approved  by  SMC  at  major  design  review  s. 

System  Level 

At  the  system  level,  design  engineering  is  a  multi-disciplinaiy  process  that  assesses  mission  operations* 
requirements  and  available  technology  for  spacecraft,  payload,  C3  and  data  processing.  A  typical  goal  for 
system  design  is  to  produce  a  balanced  design  solution  meeting  all  mission  needs  that  provide  the  lowest  life 
cost,  hi  some  cases,  schedule  and  specific  technology  requirements  may  be  the  parameters  that  drive  the 
system  design. 

Initially,  design  engineers  support  Systems  Engine ering  to  define  the  system  arc  hitec  true.  The  design  engineer 
participates  hi  trade  studies  which  partition  performance  and  functionality  between  space  and  ground 
segments,  meets  user  needs  and  disseminates  information  to  interfacing  systems.  Example  space /ground  trades 
are  processing  requirements  (flight  vs.  ground  software),  communications  links  (antenna  size,  data  rates, 
power),  orbits  and  ground  station  siting,  and  data  latency  allocations.  Design  engineers  validate  the  flowdown 
of  requirements  to  lower  levels  to  assure  that  there  is  a  credible  technology  solution(s)  and  that  these  solutions 
fully  implement  the  operations  concept.  SMC  participates  by  conducting  reviews,  controlling  the  trade  space 
and  decision  process. 

As  the  program  enters  preliminary  system  design,  allocated,  and  interface  design  selections  may  have  been 
determined  in  prior  program  concept  and  technology  development  phases.  Some  early  phase  technology  and 
make-or-buy  decisions  may  constrain  space  and  ground  systems  designs  down  to  the  component  level.  The 
impacts  of  these  early  design  decisions  fix  costs,  constrain  Technical  trades,  and  often  constrain  system 
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performance  and  operations  when  operational  concepts  are  selected,  technology  choices  are  determined,  and 
system  level  definition  documents  the  system  and  allocated  baseline 


As  a  program  evolves,  design  engineering  focuses  on  the  design  of  segment  and  subsystems,  interfaces, 
verification,  integration  and  test,  and  provides  support  during  operations  and  maintenance.  Generally,  lead 
engineers  assigned  within  the  Program  Office  systems  engineering  organization  and  lead  engineers  assigned  to 
system,  segment,  or  product  development  IPTs  fiilfili  the  design  engineers'  role  described  below.  In  addition, 
SMC  design  engineers  support  all  program  acquisition  Milestones,  with  pi  arming,  engineering  and 
programmatic  inputs.  The  following  sections  discuss  design  engineering  for  ground  systems  and  space, 
respectively. 

Ground  System 

At  the  ground  system  level,  design  engineering  validates  the  flow-down  of  requir  ements  by  demonstrating  the 
availability  of  implementable  solutions  and  assessing  risks  for  technology  development.  The  ground  system 
design  engineer  seeks  implementation  solutions  for  mission  operations.  C3,  mission  data  processing,  training 
and  operations  and  maintenance  support. 

Ground  System  Subsystem  Design 

SMC  Program  Office  ground  system  design  engineers  may  specialize  hi  a  particular  technology,  system 
component  or  device  as  shown  in  Table  6,  Several  subsystem  engineering  disciplines  support  the  design 
integration  activities  at  the  ground  segment  level. 

Table  6  SMC  Ground  Subsystem  Engineering 


Design  Disciplines 

SMC  Responsibilities 

Spacecraft  Operations 

*  Support  Acquisition  Process 

Mission  Planning 

*  Define  operational  constraints 

Ground  Communications 

•  Support  CONOPS  development 

Personnel  Training 

*  Lead  Interface  working  groups 

O&M  Support 

*  Participate  in  program  IPTs 

Mission  Data  Processing 

*  Control  ground  trades  and  decisions 

Software  Development 

•  Oversee  contractor  technical  performance 

Facilities 

*  Assess  programmatic  performance 

Ground  segment  subsystem  design  engineers  are  instrumental  in  planning  and  implementing  technology 
maturity  strategies,  assisting  definition  of  technology  demonstrations,  and  performing  assessments  of 
technology  readiness.  The  subsystem  design  engineer  also  assists  in  definition  of  developmental  risk 
mitigations  through  prototyping,  qualification  testing,  and  analyses  and  is  a  primary  participant  in  technology 
studies,  design  trades,  make-or-buy  decision  process,  and  a  vital  contributor  to  design  reviews. 

Space  System 

At  the  space  system  level,  design  engineering  validates  the  flowdowu  of  by  demonstrating  the  availability  of 
implementable  solutions  and  asses  sing  risks  for  teclmology  development.  The  space  system  design  engineer 
seeks  implementation  solutions  for  the  spacecraft,  payloads,  communications,  and  flight  software. 
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Space  System  Subsystem  Design 

Tills  SED  addresses  the  SMC1  Program  Office  space  system  design  engineer  that  specializes  in  a  particular 
technology,  system  component  or  device.  Most  SMC  Programs  rely  heavily  upon  space  system  engineers  that 
specialize  in  design  disciplines  as  shown  hi  Table  7.  These  design  engineers  provide  insight  into  the 
engineering  and  operational  limitations  of  a  design  and  its  adequacy  to  meet  stated  requirements  and  niter  face 
constraints. 


Table  7  SMC  Space  Subsystem  Design  Engineering 


Design  Discipline 

SMC  Responsibilities 

Payloads 

•  Support  Acquisition  Process 

Communications 

*  Define  operational  constraints  * 

Remote  Sensing 

*  Support  space  architecture  development 

Navigation 

*  Lead  1  nte  rface  workin  g  g  ro  ups 

Special  (SIGINT,  lasers,  etc.} 

*  Participate  in  program  IPTs 

Spacecraft 

•  Control  space  trades  and  decisions 

•  Validate  subsystem  requirements  1 

•  Assess  technology  options 

•  Participate  in  risk  managemenl/mitigation 

•  Monitor  and  assess  V&V  activities 

•  Provide  authority  to  proceed  to  manufacturing 

•  Support  system  test 

•  Oversee  contractor  technical  performance 

•  Assess  programmatic  performance  ' 

Guidance,  Navigation 

Attitude  Control 

TT&C 

Command  &  Data  Handling 

Power 

Thermal 

Propulsion 

Structures  and  Mechanisms 

Space  segment  subsystem  design  engineers  are  instrumental  hi  planning  and  implementing  payload  and  space 
technology  maturity  strategies,  assisting  definition  of  technology  demonstrations,  and  performing  assessments 
of  technology  readiness.  The  space  segment  subsystem  design  engineer  also  assists  hi  definition  of 
developmental  risk  mitigations  through  prototyping,  qualification  testing,  and  analyses  and  is  a  primary 
participant  in  technology  studies,  design  trades,  make -or- buy  decision  process,  and  a  vital  contributor  to  design 
reviews. 


Applicable  governance,  standards,  and  guidance 

Policy,  directives,  and  instructions  that  mandate  SMC  design  engineering  related  program  requirements  are 
included  in  a  wide  range  of  mandates  providing  requirements  for  acquisition,  systems  engineering,  safety, 
reliability,  T&E,  Human  Systems  Integration  (HSI).  and  others.  The  DoDI  5000.02  Design  Engineer  related 
mandates  for  SMC  acquisition  programs  include  ensuring  the  TDS  addresses  all  known  or  probable  Critical 
Program  Information  (CPI)  arid  potential  countermeasures  such  as  anti -tamper  in  the  preferred  system  concept 
and  in  the  critical  technologies  and  competitive  prototypes  to  inform  program  protection  and  design  integration 
during  the  Technology  Development  Phase. 

DoDI  5000.02  also  provides  instructions  for  the  realization  of  system  design  characteristics  that  provide 
producible,  reliable  and  maintainable  systems;  modular  open  systems:  diagnostics,  prognostics,  and  health 
management  hi  embedded  and  off-equipment  applications;  and  system  designs  that  minimize  or  eliminate 
system  characteristics  that  require  excessive  cognitive,  physical,  or  sensory  skills:  entail  extensive  training  or 
workload -intensive  tasks;  result  hi  mission-critical  errors;  or  produce  safety  or  health  hazards. 
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AEI  63-1201,  Life  Cycle  Systems  Engineering,  restates  the  5000.02  requirements  and  instructs  the  Program 
Office  Chief  Engineer  to  ensure  development  of  robust  design  solutions  that  balance  technical  and 
programmatic  requirements,  including  considerations  for  additional  capability  increments.  Robust  designs  are 
relatively  insensitive  to  variations  in  manufacturing  and  operational  environments,  and  accommodate  change 
by  incorporating  attributes  of  scalability  and  expandability. 


Table  8  below  identifies  the  significant  governance,  standards,  and  guidance  which  require  SMC  Program 
Offices  to  apply  effective  Design  Engineering  practices  to  satisfy  mandates. 

Table  8  Governance,  standards,  and  guidance  that  stnspe  tlie  Design  Engineering  discipline 


Document  Number 

Governance  Title 

Issue 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  98 

AFI  63-?01 

Acquisition  and  Sustainment  life  Cycle  Management 

22  Mar  11 

AFI  63-1201 

Life  Cycle  Systems  Engineering 

23  Jui  07 

Document  Number 

Standards  Title 

Issue 

MII-STD-1542B 

EMC  Grounding  Requirements  for  Space  System  Facilities 

15Nov9t 

MIL-STD451F 

Electromagnetic  Emissions  and  Susceptibility,  Requirements  for  the 

Control  of  Electromagnetic  interference 

10  Dec  07 

SMl>S-001 

Systems  Engineering  Requirements  arid  Products 

12  Jul  10 

SMC-S-004 

PMP  Control  Program  for  Space  and  Launch  Vehicles 

13  Jun  08 

SMC-S-005 

Space  Systems  -  Flight  Pressurized  Systems 

03  Jun  09 

SMC-S-0Q6 

Solid  Rocket  Motor  Case  Design  &  Test  Requirements 

13  Jun  08 

SMC-S-007 

Space  Battery 

13  Jun  08 

SMC-S-0G8 

Electromagnetic  Compatibility  Requirements  For  Space  Equipment  and 
Systems 

13  Jun  08 

SMC-S-017 

Lithium  Ion  Battery  for  Spacecraft  Applications 

13  Jun  08 

SMC-S-018 

Lithium  Ion  Batteiy  for  Launch  Vehicle  Applications 

13 Jun  00 

SMC-S-02Q 

Technical  Requirements  for  Wiring  Harness,  Space  Vehicle 

03  Jun  09 

AIAA  S-Q80-1998 

Space  Systems,  Metallic  Pressure  Vessel,  Pressurized  Structures,  and 
Pressure  Components 

01  Jan  98 

AIM  S-031A-2006 

Space  Systems  —  Composite  Overwmpped  Pressure  Vessels  (COPVs) 

01  Jan  06 

AIM  S-1 10-2005 

Space  Systems  —  Structures,  Slruclurai  Component,  and  Structural 
Assemblies 

12  Ju!  05 

AIM  S-11 1-2005 

Qualification  and  Quality  Requirements  for  Space-Qualified  Solar  Celts 

01  Jan  05 

AIM  S-1 12-2005 

Qualification  and  Quality  Requirements  for  Space-Qualsfed  Solar  Panels 

26  Sep  05 

AIM  S-1 13-2005 

Criteria  for  Erosive  Systems  and  Devices  Used  on  Space  and  Launch 
Vehicles 

10  Nov  05 

AIM  S-1 14-2005 

Moving  Mechanical  .Assemblies  for  Space  and  Launch  Vehicles 

30  Jun  05 

AIM  S-122-2007 

Electrical  Power  Systems  for  Unmanned  Spacecraft 

05  Jan  07 

Document  Number 

Guidance  Title 

Issue 

SMC-G-001 

Systems  Engineering  implementation  Guide 

10  Jun  09 

In  addition,  the  SMC  requirements  for  system  and  system  element  design  solution  and  validation  are  provided 
in  SMC- S -001.  SMC  guidance  to  perform  common  design  engine ering  activities  are  provided  in  SMC-G-001 
and  in  tliis  SED. 
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The  Design  Engineer  understands  the  relevant  requirements  inherent  in  the  above  directives  to  facilitate  the 
application  and  integration  of  design  considerations  into  the  Systems  Engineering  process.  As  pair  of  risk 
reduction,  the  Design  Engineer  supports  the  PM  and  Lead  Systems  Engineer  /  Chief  Engineer  to  effectively 
implement  and  manage  the  design  decision  process. 

Design  Engineers'  Contributions  to  Acquisition  Life  Cycle  Framework 

The  DoD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  Design  engineering  contributions  over  this  life 
cycle  are  best  represented  within  each  lifecycle  phase.  Figure  7  provides  the  acquisition  life  cycle  framework 
within  which  Design  Engineers  perform  as  well  as  the  products  that  the  Design  Engineers  develop  or 
contribute  to  their  development.  This  figure  provides  the  guidance  to  perform  design  engineering  planning, 
support  pre  and  post  contract  award  acquisition  activities,  and  perform  design  engineering  across  the  system 
lifecycle.  SMC  Program  Offices  establish  and  implement  design  engineering  program  strategies  and  objectives 
consistent  with  the  tenets  of  appropriate  policies,  SMC  acquisition  objectives,  and  program  objectives.  The 
Program  Office  develops,  attains  approval  for,  and  implements  design  engineering  planning  into  the  SEP  and 
liigher  level  integrated  planning  (e.g.,  IMP)  hi  accordance  with  current  DoD  policy.  Tliis  planning  is  firmly 
based  on  program  and  technical  objectives,  strategies.  DoD  mandates,  and  instructions. 

Effective  design  engineering  supports  all  of  the  major  acquisition  activities  through  the  full  system  life  cycle. 
The  Design  Engineer  sufficiently  defines  the  engineering  related  program  plaiming  to  satisfy  design 
engineering  requirements  to  achieve  overall  program  objectives.  The  initial  planning  specifies  tasks  and 
functions  to  be  performed,  timing  of  tasks,  resources  required,  and  products  to  be  developed.  Tliis  planning 
then  forms  the  basis  for  the  development  of  the  program  design  engineering  (or  systems  engineering) 
Operating  Ins Iruction  (OI).  Die  Design  engineering  planning  and  OI  are  then  reflected  appropriately  in  the 
SEP,  WB S,  IMS,  and  other  program  documents  that  address  design  engineering  related  elements.  The  Design 
Engineer  delineates  the  strategy  for  integrating  a  solid  technical  decision  process  into  the  overarching  systems 
engineering  process.  The  design  engineering  planning  is  executed  concurrently  with  the  Program  Office 
Operating  Instruction  that  documents  the  process  to  perform,  control,  and  integrate  ail  engineering  and 
management  activities  for  each  phase  of  acquisition. 

The  SMC  Program  Office  design  engineering  planning  (usually  contained  in  the  SEP  and  the  detailed 
engineering  program  planning)  and  process  descriptions  (OIs)  are  also  based  upon  the  appropriate  program - 
approved  life  cycle.  Die  following  subsections  delineate  design  engineering  contributions  to  acquisition 
activities  and  products  by  DOD  acquisition  Phase.  Also  refer  to  SMC-G-001  for  a  more  complete  list  of  design 
engineering  activities  and  products  that  are  prepared  by  the  Program  office  and  then  Contractors. 


MSA  Phase  -  SMC  Acquisition  Products 


ASP,  IDS,  DMSTES 


LC  Cost  Estimate 


1.  Materiel  Solution  Analysis.  During  this  phase  the 
Design  Engineer  provides  inputs  to  and  supports  most 
program  acquisition  activities  to  include  the 
development  of  the  acquisition  strategy  and  technology 
development  strategy,  inputs  to  the  cost  estimates. 
solicitationTlEP  development  for  Contractor  studies.  The 
Design  Engineer  may  lead  or  support  evaluations  of 
alternative  concept  solutions  and  identification  of  potential  critical  technologies  and  identification  of 


RFP  inputs  (Design  solutions  or  constraints;  concept 
development  /  assessment  requirements) 


APB,  SEP,  LCMP 
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competitive  prototypes.  The  Design  Engineer  also  contributes  to  the  development  of  tlie  MSA  Phase 
acquisition  products. 

2.  Technology  Development*  The  Design  Engineer 
provides  inputs  and  supports  program  acquisition 
activities  to  include  development  of  the  acquisition 
strategy,  updates  to  the  cost  model  and  the  Cost  .Analysis 
Requirements  Document  (CARD),  solicitation' REP 
development  and  proposal  evaluation  activities.  The 
Design  Engineer  also  contributes  to  the  development  and 
updates  to  the  ID  Phase  acquisition  products.  The  Design 
Engineer  may  lead  or  support  technology  trades, 
teclmology  advancement  strategies,  technology  rea duress 
assessments,  critical  teclmology  assessments,  and  evaluations  of  alternative  solutions.  The  Design 
Engineer  begins  to  document  technical  solutions  decisions  (see  section  below  Design  Engineers’ 
Contributions  to  Engineering  Life  Cycle  Framework). 

The  Design  Engineer  identifies  contract  requirements  relating  to  the  evolving  design  and  known  design 
constraints,  design  /  prototyping  related  tasks,  test  <fc  demo  requirements  to  meet  design  engineering 
objectives.  The  Design  Engineer  also  contributes  to  the  development  and  updates  to  other  TD  Phase 
acquisition  products. 

3 .  E  u  ginee  riag  &  Mauufa  c  tu  tin  g  Development. 

During  tins  phase,  Design  engineering  efforts  are 
concentrated  on  evolving  and  analyzing  the  system  design 
to  assure  that  1)  the  design  is  evolving  consistent  with  the 
baselined  requirements,  2)  design  qualification  is 
progressing  consistent  with  the  contract  requirements,  3) 
the  fielded  system  will  conform  to  regulatory 
requirements. 


The  Design  Engineer  also  provides  inputs  to  and  supports  program  acquisition  activities  to  include  updates 
to  the  acquisition  strategy  and  updates  to  the  cost  model  to  reflect  the  actual  technical  solutions  baselined 
and  updates  to  the  CARD.  The  Design  Engineer  supports  the  solicitation/REP  development  and  proposal 
evaluation  activities  which  include  providing  the  technical  inputs  including  technical  requirements, 
compliance  standards,  engineering  approaches,  incentives,  and  warranty  programs  to  meet  program 
objectives.  The  Design  Engineer  identifies  other  contract  requirements  as  necessary  to  meet  design 
engineering  requirements  and  program  objectives.  The  Design  Engineer  also  contributes  to  the 
development  and  updates  to  the  EMD  Phase  acquisition  products. 


EMD  Phase  -  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS _ 

CARD  update _ 

RFP:  design  objectives  in  tine  S00;  design  related 
tasks  in  SOW;  SMC-  Design  standards  -  tailored; 
design  baseline  descriptions _ 

APB:  Eng  objectives  &  related  concept  descriptions 
Detailed  design  related  planning,  SEP,  LCMPr  TEMP 


TD  Phase  —  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS _ 

LC  Cost  Estimate  Update  /  CARD  Development 
RFP:  design  objectives  in  [he  S00;  design  related 
tasks  in  SOW;  SMC-  Design  standards  -  tailored 

APB:  Technology  objectives  &  related  concept 
descriptions _ 

Detailed  technology  development  planninq,  SEP, 
LCMPh  TEMP 
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Figure  7  Acquisition  life  cycle  process  for  SMC  Desigu  Euginceiing 
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4.  Production  &  Deployment,  Operations  &  Support* 

During  the  Production  and  Deployment  phase.  Design 
efforts  are  concentrated  on  the  evaluation  proposed 
engineering  changes,  assessments  of  production  and 
fielding  tests,  and  production  and  fielding  challenges  that 
potentially  alter  the  baselined  design.  The  Design 
Engineer  provides  inputs  to  and  supports  program 
acquisition  activities  to  include  updates  to  the  acquisition 
strategy  and  updates  to  the  cost  model  to  reflect  the  actual 
technical  solutions  determined  The  Design  Engineer  supports  the  sohcitation/RFP  development  and 
proposal  evaluation  activities.  The  Design  Engineer  identifies  other  contract  requirements:  production  and 
field  test  &  demo  requirements;  field  performance  and  sustainment  analyses  to  meet  program  objectives. 
At  the  end  of  its  useful  life,  the  Design  Engineer  ensures  that  the  system  is  demilitarized  and  disposed  of 
in  accordance  with  all  legal  and  regulatory  requir  ements  and  policy. 

Design  Engineers'  Contributions  to  Engineering  Life  Cycle  Framework 

Relationship  to  the  SE  Organization 

The  Design  Engineer  plans  and  executes  the  essential  design  engineering  efforts  in  an  integrated  and  effective 
manner  wifiiin  the  context  and  full  support  of  the  overarching  Systems  Engineering  function.  The  Design 
Engineer  ensures  that  their  SED  contributions  are  timely,  adequate,  consistent,  and  compliant.  The  Design 
Engineer  ensures  that  then  contributions  are  channeled  through  the  Systems  Engineering  Analyses  and  Confrol 
activity. 

Systems  Engineers  manage  the  engineering  process  and  activities  depicted  in  Figure  3  wiiile  the  Design 
Engineer  contributes  to  this  process.  The  Design  Engineer  may  be  designated  to  be  the  process  owner  of  the 
Design  Solution  element  of  the  process  as  well  as  select  Analyses  &  Control  activities.  The  set  of  activities 
associated  with  the  design  solution  (synthesis)  element  is  described  in  the  SMC  Systems  Engineering  Primer 
and  Handbook. 

In  addition  the  Design  Engineer  defines  and  provides  the  roadmap  to  realize  system  design  characteristics  that 
provide  producible,  reliable  and  maintainable  systems;  modular  open  systems;  diagnostics,  prognostics,  and 
health  management  in  embedded  and  off- equipment  applications;  and  system  designs  that  minimize  or 
eliminate  system  cliaract eristics  that  require  excessive  cognitive,  physical,  or  sensory  skills;  entail  extensive 
training  or  workload -intensive  tasks;  result  hi  mission-critical  errors;  or  produce  safety  or  health  hazards.  Table 
9  below  highlights  typical  design  characteristics  that  are  addressed  in  SMC  space  systems  acquisition 
strategies,  transformed  into  system  requirements,  and  implemented  through  design  practices. 


P&D  /  O&S  Phase  -  SMC  Acquisition 
Products 


Updates  to  ASP,  TPS,  QMS _ 

REP:  design  objectives  in  the  SGO,  design  related 
tasks  in  SOW;  SMC-  Design  standards  -  tailored 
Detailed  planning,  SEPr  LCMP,  TEMP  updates 
CARD  update 


Design 
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Table  9  Typical  Design  Characteristics  Addressed  in  SMC  Space  Systems  Acquisition  Strategies 


Design 

Characteristic 

Characteristic  Descriptions 

Source 

Producible 

Design  analyses  for  manufacturing  efficiencies 

Manufacturing  SED 

Reliable 

Design  analyses  and  test  to  determine  product  life.  Failure 
analyses  to  model  system  reliability  and  determine  potential 
failure  modes  and  remedy  reliability  issues 

SMCI 63-1201  SMC  RAM 
Instruction 

Maintainable 

Design  analysis  to  determine  ease  of  maintenance  and  remedy 
maintai natality  issues 

SMCI  63-1201  SMC  RAM 
Instruction 

Modular  Open  Systems 

Design  for  open  systems  Incorporates  the  six  basic  elements  of 
an  open  architecture  into  all  design  considerations  and  trades: 
open-standards,  interoperable,  interchangeable,  portable, 
modular,  and  scalable.  Design  for  desirable  attributes  of  modular 
units  such  as  low  coupling,  high  cohesion,  and  low  connectivity 

SMC  Systems  Engineering 

Primer  and  Handbook 

Diagnostics,  Prognostics, 

Design  for  autonomous  or  prompted  space  systems  fault 

SMCI  63-1201  SMC  RAM 

&  Health  Management 

detection,  isolation,  and  management 

Instruction 

Interoperable 

Design  for  interoperability  Systematically  derive  the  system 
functionality  from  the  operationally  stated  interoperability 
constraints.  Collaborate  functional  and  physical  interface 
architectures,  requirements,  and  designs  across  systems 
operators,  maintained 

CJCSI 6212  01E  Interoperability 
and  Supportability  of  Information 
Technology  &  National  Security 
Systems 

Scalable  &  Expandable 

Plan  and  design  for  growth  to  support  future  needs:  physical 
expansion,  increased  capacity,  improved  performance.  Define 
growth  strategies,  requirements,  and  design  characteristics. 

SMC  Systems  Engineering 

Primer  and  Handbook 

Interchangeable 

Design  practice  to  select  common  parts,  materials,  processes 
components:  reuse  software,  documentation,  and  procedures. 

SMC  Systems  Engineering 

Primer  and  Handbook 

The  Design  Engineer  supports  concept  and  architecture  development  and  analyses;  modeling  and  simulation 
efforts;  technology  studies,  and  technology  advancement  efforts.  The  Design  Engineer  develops/derives  design 
related  requirements  and  supports  the  requirements  analyses  and  allocations  process.  He/she  also  participates 
and  sometimes  manages  the  technical  studies  and  technical  solutions  trades.  The  Design  Engineer  provides 
design  analyses  contributions  to  determine  or  assess  design  characteristics,  propose  alternative  solutions,  and 
determine  mitigating  actions  or  solutions  to  problems  or  identified  risks  through  prototyping  efforts.  The 
Design  Engineer  also  works  closely  with  the  Systems  Engineers  performing  interface  analyses  and  functional 
analyses.  The  Design  Engineer  also  supports  the  integration  and  verification  and  validation  planning  and 
execution. 

hi  performing  the  management  and  control  function,  the  Systems  Engineer  effectively  integrates  all 
engineering  functions  through  the  full  system  life  cycle.  The  Design  Engineer  ensures  their  technical 
contribution  to  the  overall  engineering  advances  and  is  applied  through  systematic  control,  collaboration  and 
sharing  across  the  organization.  For  example,  their  products,  e.g.,  documented  design  constraints,  are  timed  to 
coincide  with  architectural  trades,  design  trades,  reliability  analyses  (fault  tree,  failure  inodes,  critical  items 
lists,  reliability  block  diagrams,  etc).  In  addition.  Design  Engineering  products  are  timed  and  applied  by  the 
other  Specialty  Engineers  to  perform  their’  unique  contributions,  and  must  be  provided  to  technical  and 
program  managers  for  decision  making. 

Relationship  to  other  SEDs 

The  Design  Engineer  SED  relationship  to  other  SEDs  rs  summarized  in  Figure  1 .  Design  Engineer  interactions 
with  the  other  SEDs  are  critical  to  perform  and  integrate  then  engineering  contributions  to  the  system 
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development  efforts.  Design  Engineers  team  with  the  architecture  engineers.  Operations  Analysts,  and  others 
to  perform  technology  assessments  and  advance  technologies.  Design  Engineers  team  with  the  requirements 
analysts  and  multiple  specially7  engineers  to  perform  technical  solutions  trades,  requirements  analyses  and 
baseline  control  of  the  design  constraints. 

The  Design  Engineer  works  closely  with  the  Manufacturing  Engineers,  QA/QE,  and  Process  Engineers  to 
ensure  the  production  environment  is  adequately  designed  and  controlled  to  preserve  the  design  during 
production,  packaging,  shipping,  and  handling. 

Tools  Selection  and  Use 

The  Design  Engineer  considers  effectiveness  and  efficiencies 
gained  by  selecting  and  usmg  the  best  choice  of  Design 
Engineering  tools  considering  the  tool  requirements  for 
identifying,  analyzing,  and  managing  the  design  requirements  and 
design  constraints:  performing  technology  trades  and  advancing 
technologies  through  maturity. 

Engineering  Activities  and  Products  over  the  Life  Cycle 

Engineering  activities  that  are  unique  to  design  engineering  include: 

•  Maintain  the  integrity  of  the  te  chnical  solutions  decision  process 

•  Manage  or  support  an  effective  technology  development  program 

•  Identify  and  analyze  design  requirements  and  constraints 

•  Ensure  the  design  baseline  is  appropriately  defined  and  managed  during  development 

Design  Analyses,  The  Design  Engineer  promotes  adherence  to  all  applicable  statutes  and  to  contractually 
designated  design  requirements  as  applicable  The  Design  Engineer  ensures  the  Contra c tor (s)  identify  and 
analyze  all  applicable  design  factors:  employs  design  teclmiques  to  mitigate  design  related  risks  or  challenges: 
avoids  use  of  products  and  materials  that  present  personnel  and  environmental  hazards  and  minimizes  life 
cycle  costs  burdens.  Design  analyses  are  performed  in  many  forms  to  essentially  ensure  that  the  final  design 
reconciles  engineering  problems  and  provides  balanced  solutions.  Design-related  tradeoffs  and  analyses  are 
presented  throughout  the  System  Engineering  process  to  identify  balanced  technical  solutions. 

Example  SMC  specifications  and  standards  program  for  space  vehicles  include  the  following  design 
categories: 

•  Structures 

•  Moving  Me  c  linnic  a  1  Assembl  i  e  s 

•  Pressurized  Hardware 

•  Electrical  Power 

•  Ordnance 

•  Parts,  Materials,  Sc  Processes 

•  Software 

Other  design  related  analyses  may  include  thermal,  shock  and  vibration,  safety,  reliability,  critical  program 
information  protection  and  design  countermeasures,  and  other  analyses.  The  following  subsections  delineate 
Design  Engineer  contributions  to  engineering  activities  and  technical  products  by  DoD  acquisition  phase. 
Refer  to  SMC-S-001  for  a  more  complete  list  of  Design  Engineer  activities  and  products  prepared  by  the 
Program  Office  and  their  Contractors. 


Typical  Design  Engineering  Functions 
Requiring  Tools 


Technology  trades _ 

Technology  Readiness  Assessments 
Design  constraints  analyses 


Design 
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1-  Materiel  Solution  Analysis*  Tills  is  the 
initial  study  phase.  Top  level 
requirements,  broad  alternative  solutions 
to  the  space  mission,  its  components, 
interfaces  and  constraints  are  defined, 
along  with  technology  development 
strategies,  risk  assessments  and  mitigation 
approaches  are  developed.  Dining  tliis 
phase  the  Design  Engineer  may  provide 
inputs  to  and  support  the  Capabilities 
Based  Assessment  process  and  the  JCIDS 
process.  The  Design  Engineer  evaluates  proposed  concepts  and  architectures  to  identify  and  assess 
implications  of  conceptual  solutions  to  unnecessarily  constraining  trade -space  and  provides 
recommendations  for  each  alternative.  The  Design  Engineer  assists  to  define  /  refine  design 
constraints  and  technology  related  requirements  to  support  the  1st  iteration  of  the  requirements 
analysis  of  the  Initial  Capabilities  Document  (ICD).  The  Design  Engineer  also  and  contributes  to  the 
development  of  the  MSA  Phase  technical  products  in  support  of  Milestone  A. 


MSA  Phase  —  Technical  Products  Requir  ed 

SMC  Design  Engineer 
Technical  Products 

Contributions  to  Other 
Organizations-  Products  j 

High  level  assessment 
proposed  concepts  &  archs 

Operational  Concepts 

Design  inputs  and  factors  for 
concept,  architecture, 
technology  studies,  and  trades 

AoA  Studies 

Design  constraints  and  design 
req’ts  (draft) 

ICD  Dev 

2,  Technology  Development*  During  this 
phase  the  Design  Engineer  continues 
reassessment  and  validation  of 
requirements,  development  of  designs  for 
alternative  mission  concepts,  perform 
architecture  trades:  develop  brass  boards 
and  prototypes  as  necessary  for  risk 
mitigation  to  provide  inputs  to  and 
supports  the  JCIDS  process  and  Milestone 
B.  The  Design  Engineer  also  supports  all 
the  engineering  activities  highlighted 
witliin  the  box  titled  Engineering 
Activities  for  System  Sc  Segment 
Development  Sc  Design  Figure  7  to  commence  system  definition  and  development.  Design  Engineer 
develops  and  contributes  to  development  of  the  TD  Phase  technical  products.  The  Design  Engineer 
typically  manages  or  ensures  effective  execution  of  the  Design  Solution  element  of  the  process.  The 
Design  Engineer  also  contributes  to  the  development  and  updates  to  the  TD  Phase  acquisition  and 
engineering  products.  The  Design  Engineer  may  lead  or  support  technology  trades,  technology 
advancement  strategies,  technology  readiness  assessments,  critical  technology  assessments,  and 
evaluations  of  alternative  solutions.  The  Design  Engineer  begins  to  document  teclmical  solutions 
decisions  (see  section  below  Design  Engineers1  Contributions  to  Engineering  Life  Cycle  Framework) 


TD  Phase  -  Technical  Products  Required 


SMC  Design  Engineer 
!  Technical  Products 

Contributions  to  Other 
Organizations’  Products 

Technology  studies  & 
assessments.  Factors  for  other 
studies/  trades 

Operational  Concepts 

Identification  of  Critical 
Technologies 

Operational  Assessments 

Design  constraints  /  reqts 

CDD 

Inputs  to  arch  dev:  physical 
elements  &  descriptions 

DoDAF  CVsr  OVs ,  ISPs 

Inputs  to  system  design, 
production,  fielding,  sustain  docs 

System  Baseline 

Documentation 

76 


SMC  Sped  a  I  fi '  Engin  eeri ??g  Disdpl  i  nes  Des  ign 

3,  Engineering  &  Manufacturing 
Development.  Design  engineer  supports 
completion  of  detailed  definition  and 
design  of  system  components, 
design/requirements  compliance  and 
verification,  development  of  test  hardware 
and  software.  Design  Engineer  continues 
to  provide  inputs  to  and  supports  the 
JCIDS  process  for  Milestone  C.  The 
Design  Engineer  supports  a  LI  the 
engineering  activities  highlighted  within 
the  box  titled  Engineering  Activities  for 
Detailed  Design  Figure  7  to  continence 
detailed  systems  definition  and 
development.  The  design  Engineer 
documents  the  evolving  design  elements, 
aligns  the  elements  to  the  specification 

tree.  CARD  architecture,  aud  DoDAF  architecture  products.  The  desigu  engineer  ensures  design 
related  constraints  and  requirements  are  defined,  analyzed,  and  managed  through  the  requirements 
development  and  management  process.  The  design  engineer  assesses  the  Contractor  design  analyses 
activities,  results  and  ensures  contract  compliance.  The  Design  Engineer  ensures  process  is  in  place  to 
report,  analyze,  and  mitigate  design  issues  during  DT&E.  The  Design  Engineer  provides  inputs  to  and 
supports  the  JCIDS  process.  Refer  to  SMC-G-001  for  Design  Engineer  activities  and  products 
typically  required  dming  each  phase.  The  Design  Engineer  develops  and  contributes  to  the 
development  of  the  EMD  Phase  technical  products. 

4,  Production  &  Deploy  meat.  Operations 
&  Support.  The  Design  Engineer 
continues  to  assess  the  design  to  determine 
if  it  meets  the  contractual  requirements 
and  that  build  and  integration  activities  do 
not  induce  additional  Design  risks.  The 
Design  Engineer  supports  technical 
baseline  engine ermg  change  activities. 

Construction  of  ground  and  flight  systems, 
system  integration  and  test,  operations  and 
maintenance  of  the  system  takes  place  in 
this  phase.  The  design  engineer  provides 

operations  and  maintenance  oversight  and  support  through  end  of  life.  The  Design  Engineer  ensures 
that  the  build  instructions  adequately  implement  the  documented  design  and  ensures  the 
manufacturing  environment  minors  the  manufacturing  design.  (This  is  usually  performed  during  the 
PCA.)  The  Design  Engineer  helps  the  Program  Office  address  end-of-life  safing.  and  space 
environments  per  AFSPC  Supplement  to  AFI  91-202.  The  Design  Engineer  develops  and  contributes 
to  the  development  of  the  Production  &  O&S  Phase  technical  products. 

Design  Engineers'  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  their-  bus  mess  model  and  approach  structure  based  primarily  on  their  program 
objectives,  program  and  technical  challenges,  organizational  structure,  as  well  as  program  and  engineering 
planning  (SEP  plus  detailed  engineering  planning). 


P&D  /  O&S  Phase  -  Technical  Products  Required 


SMC  Design  Engineer 

T  eehni c  al  Pro  d uc  t$ 

Contributions  to  Other 
Organizations'  Products 

Inputs  tech  baseline  engineering 
changes 

Supportability  assessment  Rpt 
Contribution 

Analyses  of  failures  and  mishap 
incidents 

Operational  Assessments 
Contributions 

Transition  &  Fielding  Docs 

T&E  /  Demo  Reports 

Evaluations  of  Tech  Orders, 
operations  manuals 

EMD  Phase  —  Technical  Pro  ducts  Required 


SMC  Design  Engineer 
Technical  Products 

Contributions  to  Other 
Organize  lions'  Products 

Technology  Studies, 
assessments  Factors  for  other 
studies/  trades 

Operational  Concepts 

Identification  of  Critical 
Technologies 

Operational  Assessments 

Documented  design  constraints  / 
requirements 

Capabilities  Production  Doc 
(CPD) 

Inputs  to  architecture 
development::  physical  elements 
and  descriptions  determined 
through  trades  &  analyses 

DoDAF  CVs,  OVs  ,  ISP 

Inputs  to  system  design, 
production,  fielding,  sustain  docs 

System  Baseline  Documentation 
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The  Design  Engineer  develops  and  implements  a  Design  engine enng  approach  to  achieve  Program  Office 
Design  engineering  objectives  and  requirements.  The  approach,  which  is  documented  in  the  SEP,  defines  the 
Design  Engineering  tasks  and  functions  to  be  performed  and  products  to  be  developed;  timing  of  tasks,  task 
outputs,  resources  (skills,  tools,  equipment,  and  completion  criteria).  The  Design  Engineer  plans  tasks  to 
integrate  design  activities  within  the  Program  Office,  between  Contractors  and  stakeholders.  The  Design 
Engineer  plans  the  tasks  to  establish  and  manage  the  design  solutions  and  decision  process;  technical  review 
forums;  support  SE&I  activities,  risk  management,  integration,  and  system  modifications:  coordinate  the 
engineering  planning  with  SMC  Staff  Design  Engineering  office,  integrate  design  engineering  planning  with 
other  functional  and  acquisition  plans  (i.e.,  SEP.  ASP/ Acquisition  Strategy  Document,  LCMP). 

Execution  of  the  Design  Engineer  planning  is  typically  defined 
through  an  Operating  Instruction  which  implements  SMC  and 
liigher  level  instructions,  policies,  and  directives.  The  Design 
Engineer  provides  frill  support  to  define  the  program  and 
technical  objectives  where  design  challenges  and  risks  are 
known  or  anticipated.  The  Design  Engineer  assists  to  establish 
the  business  model,  develop  program  planning  and  schedules, 
and  define  and  implement  program  processes.  The  Design 
Engineer  ensures  the  technical  solutions  elements  of  the  program 
are  appropriately  represented  hi  the  program  plans,  program 
schedules,  work  breakdown  schedules,  cost  estimates.  The  Design  Engineer  also  reports  then  technical 
performance  and  progress.  The  Design  Engineer  shares  hi  the  risk  management  responsibilities  to  identify, 
assess,  and  propose  mitigating  actions  of  design  related  risks.  They  also  support  the  program  manager’s 
problem  identification,  resolution,  and  decision-making  processes. 


SMC  Program  Management  Products 


PMD _ 

SEP,,  IMP,  IMS;  WBS _ 

Decision-making  &  problem  solving _ 

Technical  progression  and  issues  reporting 
LC  Cost  Estimate  (CARD) _ 

Processes  (01  s) _ 

Risk  Management  Inputs 


The  Design  Engineer  contributes  to  the  development  of  the  program  management  products  identified  in  the 
Table. 
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Appendix  E  -  Manufacturing  and  Producibility 

The  SMC  Manufacturing  &  Producibiity  Engineer,  hereafter  referred  to  as  Manufacturing  Engineer  (ME),  has 
the  responsibility  to  formulate  and  execute  the  Manufacturing  and  Producibility  Program  for  new  and  existing 
programs  at  SMC.  The  ME  plans  and  executes  the  essential  Manufacturing  Engineering  and  Manufacturing 
Management  for  the  contracted  manufacturing  operations  to  ensure  that  manufacturing  planning  and  operations 
are  timely,  adequate,  consistent,  and  compliant.  The  ME  ensures  that  manufacturing  engineering  contributions 
are  channeled  thr  ough  the  Systems  Engineering  Analyses  and  Control  activity. 

Applicable  governance,  standards,  and  guidance 

Policy,  directives,  and  instructions  that  mandate  manufacturing  engineering  and  management  requirements  are 
included  in  a  wide  range  of  mandates  including  those  for  acquisition,  T&E,  softwar  e,  systems  engineering,  and 
others.  Governance  specific  to  manufacturing  and  producibility  extends  from  United  States  Code  (USC)  Title 
10,  Federal  Acquisition  Regulations,  as  well  as  DoD  and  Air  Force  directives  and  instructions.  Mandated 
requirements  that  the  ME  must  address  also  span  the  Ml  acquisition  hfecycle  from  the  requirements  to  assess 
the  critical  technology1 2 3 4  elements  (CTEs)  associated  with  each  proposed  materiel  solution,  including 
manufacturing  feasibility,  and,  where  necessary,  demonstration  needs:  Industrial  Base  assessments  and 
protection;  and  continual  assessments  and  actions  to  mitigate  manufacturing  sources.  One  of  the  most 
important  tasks  for  the  SME  ME  to  accomplish  is  to  tailor  the  application  of  the  governance  and  standards  to 
the  particular  system  acquisition  to  assure  that  manufacturing  arid  producibility  are  appropriately  included  in 
the  REP  and  eventual  contract  SOW,  CDRL,  and  baseline  of  technical  requirements. 

National  Technology  and  Industrial  Base  (10  U.S.C.  2506).  The  ME  ensures  technological  and  industrial 
capability  considerations  are  integral  to  SMC  space  systems  acquisitions  practices  to  develop,  produce, 
maintain,  and  support  the  industrial  base  protection  program.  The  ME  ensures  performance  of  an  analysis  of 
the  capabilities  of  the  national  technology  and  industrial  base  to  develop,  produce,  maintain,  and  support  such 
program,  including  consideration  of  the  following  factors  related  to  foreign  dependency: 

1 . )  The  availability  of  essential  raw  materials,  special  alloys,  composite  materials,  components,  too  hug, 

and  production  test  equipment  for  the  sustained  production  of  systems  frilly  capable  of  meeting  the 
performance  objectives  established  for  those  systems;  the  uninterrupted  maintenance  and  repair  of 
such  systems;  and  the  sustained  operation  of  such  systems. 

2. )  The  identification  of  items  that  are  available  only  from  sources  outside  the  national  technology  and 

industrial  base. 

3. )  The  availability  of  alternatives  for  obtaining  such  items  from  within  the  national  technology  and 

industrial  base  if  such  items  become  unavailable  from  sources  outside  the  national  tecluiology  and 
industrial  base;  and  an  analysis  of  any  military  vulnerability  that  could  result  from  the  lack  of 
reasonable  alternatives. 

4 . )  The  effects  on  the  national  technology  and  nidus  dial  base  that  result  from  foreign  acquisition  of  firms 

in  die  United  States. 
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The  ME  also  ensures  the  following  considerations  are  integral  to  SMC  space  systems  acquisitions  practices 

L)  Consideration  of  requirements  for  efficient  manufacture  diuing  the  design  and  production  of  the 
systems  to  be  procured  under  the  program. 

2. )  The  use  of  advanced  manufacturing  technology,  processes,  and  systems  during  the  research  and 

develop  me  nt  phase  and  the  production  phase  of  the  program. 

3. )  To  the  maximum  extent  practicable,  the  use  of  contract  solicitations  that  encourage  competing 

Offerors  to  acquire,  for  use  hi  the  performance  of  the  contract,  modem  teclmology.  production 
equipment,  and  production  systems  (including  hardware  and  software)  that  increase  the  productivity 
of  the  Offerors  and  reduce  life-cycle  costs. 

4. )  Methods  to  encourage  investment  by  U.S.  domestic  sources  in  advanced  manufacturing  technology 

production  equipment  and  processes  tlirough  -(I)  Recognition  of  the  contractor's  investment  in 
advanced  manufacturing  teclmology  production  equipment,  processes,  and  organization  of  work 
systems  that  build  on  workers'  skill  and  experience,  and  work  force  skill  development  hi  the 
development  of  contract  objective;  and(ii)  Increased  emphasis  in  source  selection  on  production 
efficiency. 

5. )  Expanded  use  of  commercial  manufactming  processes  rather  than  processes  specified  by  DoD. 

6. )  Elimination  of  barriers  to,  and  facilitation  of,  the  integrated  manufacture  of  commercial  items  and 

items  being  procured  under  DoD  contracts. 

7. )  Expanded  use  of  commercial  items,  commercial  items  with  modifications,  or  to  the  extent  commercial 

items  are  not  available,  non-developmental  items 

8. )  Acquisition  of  major  weapon  systems  as  commercial  items. 

The  ME  also  ensmes  implementation  of  best  manufactming  practices  and  consistent  proven  processes  tlirough 
standardization.  Although  Mil-Std-1528A  lias  been  canceled,  it  is  a  required  compliance  standard  for  SMC 
major  acquisitions.  This  standard  contains  excellent  information  on  the  objectives  and  specific 
activities/outputs  for  Manufacturing  Management  and  Manufacturing  Engineering  and  is  tailored  for  use  on 
each  developmental  and  production  acquisition.  Table  10  below7  identifies  the  most  significant  governance, 
standards,  and  guidance  wliich  generally  apply  to  SMC  for  manufacturing  and  producibility. 

Table  10  Governance,  standards,  and  guidance  tbat  shape  the  Manufacturing  Engineering  discipline. 


Document  No 

Governance  Title 

Issue 

10  U.S.C.  2505, 2506 

National  Technology  and  Industrial  Base 

DFARS  207.1 05(b)(20)(A) 

National  Technology  and  Industrial  Base 

DFARS  Subpart  234.70 

Acquisition  of  major  weapon  systems  as  commercial  items 

DoD  Directive  4245.6 

Defense  Production  Management 

19  Jan  84 

DoDI  4200.15 

Manufacturing  Technology  Program 

19  Sep  02 

DoDI  5000  02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

DoD  4245.7-M 

Transition  from  Development  to  Production 

Sep  85 

Document  No 

Standards  Title 

Issue 

Mil-Std-1 52 8 A 

Manufacturing  Management  Program 

09  Sept  86 

Mil-Std-1540D 

Product  Verification  Reqts  for  Launch,  Upper  Stage,  and  Space 
Vehicles 

15  Jan  99 

SMC-S-Q09 

PMP  Control  Program  for  Space  and  Launch  Vehicles 

12  Jan  09 

SMC-S-010 

Technical  Requirements  for  Electronic  Parts,  Matenals,  and 

Processes  for  Space  and  Launch  Vehicles 

12  Jan  09 

SMC-S-01 1 

PMP  Control  Program  for  Expendable  Launch  Vehicles 

13  Jun  08 
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Document  No 

Guidance  Title 

Issue 

SMC  CPATS 

Manufacturing 

19  Sep  06 

DFARS  PGI 207 

Acquisition  Planning 

Mil-Hdbk-727 

Design  Guidance  For  Producibility 

5  Apr  84 

Mil-Hdbk-896 

Manufacturing  and  Quality  Program 

8  Aug  08 

www .  b  nine  oe .  ora 

Best  Manufacturing  Practices 

ME  Contributions  to  the  Acquisition  Life  Cycle  Framework 

The  DoD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  ME  contributions  over  this  life  cycle  are  initiated 
during  the  acquisition  phase.  The  ME  supports  pre  and  post  contract  award  activities,  by  stipulating 
manufacturing  requirements  and  performing  manufacturing  management  and  engineering  analyses  across  the 
system  lifecycle.  SMC  Program  Offices  establish  and  implement  manufacturing  and  producibility  program 
strategies  and  objectives  consistent  with  appropriate  policies,  SMC  objectives,  and  program  objectives.  The 
Program  Office  then  develops  manufacturing  plans  obtains  approval  for  them,  and  incorporates  manufacturing 
planning  into  the  Systems  Engine ering  Plan  (SEP)  and  liigher  level  integrated  planning  (e.g.,  IMP)  in 
accordance  with  current  DoD  policy.  Tliis  planning  is  firmly  based  on  program  and  technical  objectives, 
strategies.  DoD  mandates,  and  instructions. 

An  effective  manufacturing  and  producibility  program  supports  all  of  the  major  acquisition  activities  through 
the  full  system  life  cycle.  The  Systems  Engineering  process  assures  that  the  manufacturing  function  is 
considered  early  in  the  concept  phase  when  producibility  considerations  are  paramount  in  conducting  trade 
studies  of  the  preliminary  and  evolving  concepts.  As  system  functions  are  defined  and  solutions  are 
synthe sized!  in  the  design  evolution,  each  proposed  solution  is  evaluated  to  identify  any  producibility  concerns 
and  provide  manufacturing  alternatives  that  may  impact  the  design  to  insure  consistent  repeatability  iu  the 
hardware  manufacturing  process. 

DoD  envisions  a  prevention- based  strategy  that  encourages  continuous  improvement  across  the  industry  by 
identifying  the  most  advanced  methods  of  manufacturing  that  could  be  applied  to  the  program.  The  ME  assists 
the  Program  Office  to  identify  those  contractors  that  provide  evidence  of  using  recognized  advanced 
manufacturing  concepts  (design  for  manufacturing,  reduced  variation  and  process  control  teclmiques,  improved 
value  streams,  defect  free  products)  so  that  they  can  be  given  proper  credit  dining  the  source  selection  process 
(reference  G AO  N S LAD -96-162  Best  Practices). 

Manufacturing  and  producibility  planning  should  define  a  program  that  acliieves  the  overall  program 
objectives  and  requirements;  specifies  tasks  and  functions  to  be  performed,  timing  of  tasks,  resources  required, 
products  to  be  developed,  that  forms  the  basis  for  the  development  of  the  Manufacturing  and  Producibility 
Operating  Instruction  (OI).  The  manufacturing  planning  and  OI  are  then  reflected  appropriately  in  the  WBS* 
IMS,  and  other  program  documents  that  address  manufacturing  and  producibility  related  elements.  The 
manufacturing  planning  is  executed  concurrently  with  the  Program  Office  OI  that  documents  the  process  to 
perforin  control,  and  integrate  ail  manufacturing  engineering  and  management  activities  for  each  phase  of 
acquisition.  The  SMC  Program  Office  manufacturing  planning  is  documented  in  the  SEP  and,  the  detailed 
manufacturing  program  plans;  then  the  OI  are  based  upon  these  documents.  SMC  Program  Offices  appoint  ME 
personnel,  establish  and  implement  manufacturing  and  producibility  program  strategies  and  objectives 
consistent  with  appropriate  policies,  SMC  acquisition  objectives,  and  program  objectives. 
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1.  Materiel  Solution  Analysis.  During  this  phase  the  ME 
provides  inputs  to  and  supports  most  program  acquisition 
activities  to  include  the  development  of  the  acquisition 
strategy,  inputs  to  the  cost  estimates,  requirements  for 
sohcitation/RFP  development  for  Contractor  studies,  and 
proposal  evaluation  criteria.  The  ME  also  contributes  to 
the  development  of  the  MSA  Phase  acquisition  products 
that  are  impacted  by  or  impact  manufacturing  and  producibility. 

2.  Technology  Development.  The  ME  identifies 
manufacturing  technology  acquisition  activities  that  may 
be  needed  to  produce  the  software  and/or  equipment  for 
the  new  system.  These  efforts  may  include  development 
of  an  acquisition  strategy,  updates  to  cost  models  and 
development  of  Cost  Analysis  Requirements  Descriptions 
(CARD),  solicitation  RFP  requirements  and  proposal 
evaluation  criteria.  The  ME  identifies  other"  contract 
requirements  such  as  incentives/warranty  programs,  and  design  for  manufacturing  requirements  to  meet 
program  objectives.  The  ME  also  contributes  to  the  development  and  updates  to  the  TD  Phase  acquisition 
products. 

3.  Engineering  &  Manufacturing  Development*  The  ME 
evaluates  and  approves  supplier  manufacturing  plans  and 
schedules  so  that  they  meet  overall  program  timing 
requirements.  The  ME’s  effort  includes  updates  to  the 
acquisition  strategy  and  updates  to  the  cost  model  to 
reflect  the  actual  technical  solutions  determined  and 
updates  to  the  CARD.  The  ME  supports  the 
solicitation/RFP  development  and  proposal  evaluation 
activities  which  include  providing  the  technical  inputs  including  teclmicai  manufacturing  requirements, 
manufacturing  compliance  standards  manufacturing  engineering  and  process  control  approaches, 
incentives,  and  warranty  progr  ams  to  meet  program  objectives.  The  ME  also  develops  updates  to  the  EMD 
Phase  acquisition  products  related  to  manufacturing  and  producibility. 


EMD  Phase  —  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  QMS _ 

CARD  update _ 

RFP:  Mfg  requirements  in  the  S00;  Mfg  related  tasks 
in  SOW,  Mfg  data  products  in  CDRLs;  SMC-  parts, 
materials,  processes  standards  -  tailored _ 

SSP:  Evaluation  criteria  for  mfg/producibility _ 

APB:  Mfg  requirements  &  related  concept  descriptions 

Detailed  Mfg  planning,  SEP,  LCMP;  TEMP  updates 


TD  Phase  -  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS _ 

1C  Cost  Estimate  Update  /  CARD  Development _ 

RFP:  Manufactunng  requirements  in  the  S00r  Mfg 
related  tasks  in  SOW,  Mfg  data  products  in  CDRLs; 
SMC-  parts,  matenals,  processes  standards  -  tailored 

SSP:  evaluation  criteria  for  manufacturing/producibility 

APB:  Mfg  objectives  &  related  concept  descriptions 

Detailed  Mfg  planning,  SEP,  LCMP,  TEMP 


MSA  Phase  -  SMC  Acquisition  Products 


PMD _ 

ASP,  TPS.  DMS,  TES 

LC  Cost  Estimate _ 

RFP  inputsfmanufacturing  requirements; 

Man ufactu ring/ prod u cib il i ty  assessment  requirements) 

J  i,  CCA _ 

SSP,  SEP;  LCMP 
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Assess  Contractors'  Compliance 
to  Mfg  Requirements 


Assess  Contractors'  Mfg  Program  4 
Compliance  to  Mlg  Requirements 


Review  Contractors'  Tedhucaf 
Data  for  accuracy 


Assess  Contractors'  Concepts 

(Including  Main!  Concept  & 
Technology  Choices 


Disseminate  Mfg  1  ethnical 
Information  among  Stakeholders 


Assess  Reliability  Analyses.  QAE 
Analyses 


Review  Contractors'  Mfii  Critical 
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Figure  S  Acquisition  life  cycle  process  for  SMC  .Manufacturing  and  Producibility 
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4*  Production  &  Deployment,  Operations  Sc  Support.  During 
this  phase  the  ME  monitors  the  performance  of  the 
suppliers  in  providing  the  system  software  and 
equipment.  The  ME  provides  inputs  to  and  supports 
acquisition  activities  that  are  related  to  manufacturing 
including  updates  to  the  acquisition  strategy,  the  cost 
model  and  the  CARD;  to  reflect  the  actual  technical 
solutions.  The  ME  supports  any  solicitation/RFP 
development  and  proposal  evaluation  activities  that  may  be  required.  The  ME  identifies  other  contract 
requirements  such  as  value  stream  and  process  cycle  efficiency  analysis,  production  process  capability 
analysis  (hi  conjunction  with  the  Quality  Engineer),  critical  manufacturing  steps  and  tests  to  ver  ify  product 
design  conformance,  inc enti ves/warranty  programs. 

ME  Contributions  to  the  Engineering  Life  Cycle  Framework 

Relationship  to  the  SE  Organization 

The  ME  plans  and  executes  essential  manufacturing  engineering  and  management  efforts  within  the  context 
and  Ml  support  of  the  overarching  Systems  Engineering  Miction.  The  ME  ensures  that  each  Manufacturing 
and  Producibility  SED  contribution  is  timely,  adequate,  consistent,  and  compliant,  and  that  their  contributions 
are  channeled  through  the  Systems  Engineering  Analyses  and  Cot  mot  activity.  Systems  Engineers  manage  the 
engineering  process  and  activities  depicted  in  Figure  3  and  the  ME  contributes  to  tills  process.  The  ME 
develop  s/derives  die  program  specific  manufac  turing/pro  due  ibility  requirements  and  supports  the  requirements 
analyses  and  allocations  process.  They  also  participate  in  teclmical  studies  and  solutions  trades  when 
manufacturing  methods  are  a  factor  and/or  schedules  may  be  impacted.  They  provide  design  analyses 
contributions  to  determine  the  appropriate  level  of  manufac  luring  surveillance  through  analyses,  demo, 
inspection,  and  test. 

The  ME  also  works  closely  with  the  System  Engineers  performing  interface  analyses,  functional  analyses,  and 
die  integration  and  verification  and  validation  planning  and  execution.  The  ME  works  closely  with  the  Quality 
Assurance  Officer/E ngineer  (QAOE)  and  Reliability  and  Maintainability  (RAM)  Engineer  to  ensure  quality 
and  reliability  through  controlled  and  predictable  quality  levels  during  production,  handling,  storage, 
packaging,  and  transportation. 

In  support  of  the  overall  program  management  and  control  Miction,  the  ME  monitors  and  integrates  all 
manufacturing  engineering  functions  tlnough  the  full  system  life  cycle.  The  ME  ensures  that  effective 
informational  and  process  control  teclmiqires  and  advances  are  applied  for  systematic  MScP  control, 
collaboration  and  sharing  across  the  organization.  For  example,  some  key  lean  manufacturing  process  con  hoi 
indicators  are  Process  Cycle  Efficiency  =  Value  Added  Time/Total  Lead  Time;  and  Process  Capability  (Cpk)  = 
Process  spread/specification  tolerance  and  comparison  to  target  value.  The  ME  ensures  their  technical 
contribution  to  the  overall  systems  engineering  is  appropriately  applied  tlnough  systematic  control, 
collaboration  and  sharing  across  the  organization.  Since  a  do-it-right-the-fir st-time  mindset  must  be  realized  by 
all  acquisition  specialists,  the  ME  works  closely  with  other  specialty  engineers  in  defining  and  accomplisliing 
the  product  quality  expectations.  As  any  program  evolves  there  are  inevitable  refinements  and  changes  that  can 
impact  the  manufacturing  process.  The  ME  must  be  able  to  react  to  program  changes  to  assure  that  schedule 


P&D  /  O&S  Phase  -  SMC  Acquisition 
Products 


Updates  to  ASP,  TPS,  QMS _ 

RFP:  Mfg  requirements  in  tine  S00;  Mfg  related  tasks 
in  SOW,  Mfg  data  products  in  CDRLs;  SMC-  Parts, 
materials  and  processes  standards  -  tailored _ 

SSP:  evaluation  criteria  for  Mfq/producibility _ 

Detailed  Mfg  planning,  SEP,  LCMPr  TEMP  updates 

CARD  update 
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and  cost  impacts  are  minimized.  lo  addition,  the  ME  products  and  metrics  are  timed  and  applied  by  the  other 
Specialty  Engineers  to  perform  then  unique  contributions,  and  must  be  provided  to  technical  and  program 
management  for  decision  making. 


In  addition,  the  ME  works  closely  with  the  Quality  Engineer  and  RAM  Engineer  to  identify,  assess  and  address 
process  and  workmanship  concerns  that  may  potentially  impact  product  qualify  and  reliability,  and  to  review" 
process  improvement  opportunities. 

Tools  Selection  and  Use 

The  ME  considers  effectiveness  and  efficiencies 
gained  by  selecting  and  using  the  best  choice  of 
manufacturing  tools  for  manufacturing/ 
producibihty  system  analyses,  T<K:E,  information 
sharing,  automated  data  exchanges  with  other 
tools,  and  other  considerations. 

Engineering  Activities  and  Products  over  the  Life  Cycle 

The  following  subsections  delineate  ME  contributions  to  engineering  activities  and  technical  products  by  DoD 
acquisition  phase.  Refer  to  Mil-Std-1528A  and  the  SMC  CPAT  for  Manufacturing  for  a  more  complete 
description  of  manufacturing  activities  that  are  performed  by  the  Program  Office  and  then  contractors. 


Typical  Mfg  Functions  Requiring  Tools 


Process  Capability  (Cpk) _ 

Mfg  Requirements  Analyses  &  Allocations  +  Metrics 

Process  Cycle  Efficiency _ 

Value/Value  Stream  Analysis _ 

Theory  of  Constraints  Analysis 


1. 


2. 


Mate  lid  Solution  Analysis*  During  this 
phase,  the  ME  may  proride  inputs  to  and 
support  the  Capabilities  Based  Assessment 
process  and  the  JCIDS  process.  The  ME  also 
contributes  to  the  development  of  the  MSA 
Phase  technical  products. 


Technology  Development*  During  this 
phase  the  ME  continues  to  provide  inputs  to 
and  supports  the  JCIDS  process.  The  ME 
also  supports  all  the  engineering  activities 
highlighted  within  the  box  titled 
Engineering  Activities  for  System  &  Segment 
Development  <E  Design  Figure  8  to 
commence  system  definition  and 
development.  The  ME  contributes  to 
development  of  the  TD  Phase  technical 
products. 


MSA  Phase  —  Technical  Products  Required 

SMC  ME  Technical 

Products 

Mfg  Contributions  to  Other 
Organization ’s  Products 

High  level  Mfg/Prod  uci  b  i  tity 

requirements  analysis 

Operational  Concepts 

ME  inputs  for  concept,  arch, 
technology  studies  and  trades 

AoA  Studies 

Mfg  System  Reqts  (draft) 

Initial  Capabilities  Doc  (ICD)  Dev 

Roadmap  inputs  -  mitigations  of 
critical  process  points/  nsks 

DoDAF  CVs3  OVs 

TD  Phase  —  Technical  Pro  ducts  Required 

SMC  VIE  Technical 

Products 

Mfg  Contributions  to  Other 
Organization's  Products 

Inputs  to  System  Concepts 

Operational  Concepts 

Factors  for  Mfg  applications 

Operational  Assessments 

MfgTech  Reqts3  TRD3  SRD, 
Specifications,  ICDs,  Standards 
Selection/  Tailor 

Capabilities  Development  Doc 
(CDD) 

PDRs,  CDRs 

Mfg  inputs  to  ISP 

DoDAF  CVs3  OVs 

Mfg/Prod  uci  bili  ty  Program 

Analysis  Reports 

Mfg  Management  Reviews 

Manufacturing 
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3*  Engineering  &  Manufacturing 
Development-  The  ME  continues  to  provide 
inputs  to  and  support  the  JCIDS  process. 

The  ME  supports  ail  the  engineering 
activities  highlighted  within  the  box  titled 
Engineering  Activities  for  Detailed  Design 
Figure  8  to  commence  detailed  systems 
definition  and  development.  The  ME 
establishes  a  manufacturing  management 
repotting  system  across  contractor's.  The 
activities  of  the  ME  during  this  phase  are 
important  to  assure  the  contractor  is  building 
tilings  right  the  fust  time  per  design 
requirements  and  with  minimal  waste.  Refer 
to  Mil-Std  152  8 A  and  SMC  Manufacturing  CP  AT  for  manufacturing  program  requirements  and  activities. 
The  ME  develops  and  contributes  to  the  development  of  the  EMD  Phase  technical  products  to  assure  a 
high  level  of  manufactured-in  quality. 

4*  Production  &  Deployment,  Operations  & 

Support*  The  ME  continues  to  provide 
inputs  to  and  supports  the  JCIDS  process. 

The  activities  of  manufacturing  during  tins 
phase  are  extensive.  Refer  to  Mil-Std- 1 528 A 
and  SMC  Manufacturing  CPATS  for  ME 
activities  and  products  typically  performed 
timing  each  phase.  The  ME  develops  and 
contributes  to  the  development  of  the  P&D  / 

O&S  Phase  technical  products. 

ME  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  their  business  model  and  approach  structure  based  primarily  on  their  program 
objectives,  program  and  technical  challenges,  organizational  structure,  as  well  as  program  and  engineering 
planning.  The  ME  develops  and  implements  the  manufacturing  and  profitability  program  planning  to  support 
program  objectives  and  requirements.  The  planning  defines  the  manufacturing  engineering  tasks  and  functions 
to  be  performed  and  products  to  be  developed;  timing  of  tasks,  task  outputs,  resources  (skills,  tools, 
equipment),  and  completion  criteria.  The  ME  plans  tasks  to  integrate  contractor  manufacturing  activities  within 
the  program  office,  between  Contractors  and  stakeholders.  The  ME  plans  the  tasks  to  establish  and  manage  the 
Manufacturing  and  Producibility  program;  support  SE&I  activities,  e.g..  production  process  controls,  V&V 
activities,  risk  management,  integration,  system  modifications,  contractor  manufactiuing  performance 
requirements;  coordinate  the  manufacturing  planning  with  the  SMC  Manufacturing  and  Producibility  OPR, 
operating  commands,  supporting  commands,  and  test  agencies:  and  integrate  manufactiuing  planning  with 
other  functional  and  acquisition  plans  {i.e.  SEP.  ASP,  LCMP). 


P&D  /  O&S  Phase  -  Technical  Products  Required 


SMC  ME  Technical 

Products 

Vlfg  Contribution*  to  Other 
Organization'*  Products 

Inputs  to  tech  baseline/ 
engineering  changes 

Sup  portability  Analyses  Rpt 

Analyses  of  contractor  mfg 
reports  and  test  reports 

Operational  Assessments 

Hardware  Acceptance  Reviews 
(HARs) 

Transition  &  Fielding  Docs 

Logistics  Reports 

Mfg  Analyses  Reports 

Management  System  Reviews 

Process  capability  and  cycle 
efficiency  reports 

Program  Performance  Reviews 

EMD  Phase  -  Technical  Products  Required 


SMC  ME  Technical 

Products 

Mfg  Contiibutious  to  Other 
Organization's  Products 

Update  System  Concept 

Operational  Concepts 

Validate  preferred  mfg 

applications 

Operational  Assessments 

Mfg  System  Tech  Reqts,  TRD, 
SRD,  Spec,  ICDs 

Capabilities  Production  Doc 
(CPD) 

Inputs  to  system,  production, 
fielding,  sustain  design  docs 

Manufacturing  Readiness 

Reviews  (MRRs),  Test  Readiness 
Reviews  (TRRs 

Mfg  inputs  to  ISP 

DoDAF  CVs,  OVs 

Mfg/Producibilify  Program 

Analysis  Reports 

Management  Reviews 

Process  Ca  pa  bi  I  ity/  Efficiency 

Contractor  assessments 
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Execution  of  the  manufacturing  planning  is  typically  defined  through  an  Operating  Instruction  (OI).  Hie  ME 
helps  define  the  program  and  technical  objectives  by  identifying  where  manufacturing  management  and 
engineering  should  be  applied.  The  ME  assists  to  establish  the  business  model  develop  program  planning  and 
schedules,  and  to  define  and  implement  program  processes.  The  ME  ensures  the  manufacturing  and 
producibility  components  of  the  program  are  appropriately  represented  in  the  program  plans,  program 
schedules,  work  breakdown  schedules,  and  cost  estimates.  The  ME  also  evaluates  and  reports  the  assigned 
program  contractor’s  technical  performance  and  progress. 

They  support  the  program  manager’s  problem  identification, 
resolution,  and  decision-making  processes. 


The  ME  provides  inputs  to  the  development  of  the  program 
management  products  identified  in  the  Table. 


SMC  Program  Management  Product' 


PMD _ 

SEP,  IMP,  [MS,  WBS _ 

Decision-making  &  problem  solving  inputs 

Technical  progression  and  issues  repotting 

LC  Cost  Estimate  (CARDs) _ 

Processes  (01s) _ 

Risk  Management  Inputs 
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Appendix  F  -  Quality  Assurance 

The  SMC  Quality  Assurance  Executive  (QAE)  has  the  responsibility  to  update  and  execute  the  Quality 
Assurance  Program.  The  QAE  plans  and  executes  the  essential  QiiaLty  Assurance,  Quality  Engineering,  and 
management  efforts  in  an  integrated  and  effective  manner  to  ensure  that  each  QA  Specialty  Engineering 
Discipline  contribution  is  timely,  complete,  consistent,  and  compliant.  Hie  QAE  ensures  that  their 
contributions  are  channeled  through  the  Systems  Engineering  Analyses  and  Control  activity. 


Applicable  governance,  standards,  and  guidance 

Policy,  directives,  and  instructions  that  mandate  quality  assurance  related  program  requirements  are  included  in 
a  wide  range  of  mandates  including  those  providing  requirements  for  acquisition,  T&E,  software,  Sys terns 
Engineering,  and  others.  All  SMC  acquisitions  require  a  quality'  program!  Table  11  below  identifies  the  most 
significant  governance,  standards,  and  guidance  which  generally  require  SMC  compliance  for  Quality 
Assurance 

Table  11  Governance,  standards,  and  guidauce  that  slMfipe  the  Quality  Assurance  Engineering  discipline. 


Document  No 

Governance  Title 

Issue 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

OoDI  4715.15 

Environmental  Quality  Systems 

11  Dec  06 

AF!  63-501 

Air  Force  Acquisition  Quality  Program  &  Supplement  1 

31  May  94 

1  May  98 

AF!  63-1201 

Life  Cyde  Systems  Engineenng 

23  July  07 

Document  No 

Standards  Title 

Issue 

SAE-AS  9100,  Rev  8 

Quality  Systems-Aerospace  Model  for  QA  Design,  Development, 
Production,  Installation,  and  Service 

06  Jan  04 

ISO  9001:2008 

Quality  Management  System-Requirements 

13  Nov  08 

AS  9100:2009 

Quality  Management  Standard  for  Aviation,  Space,  and  Defense 

Industries 

15  Jan  09 

SMC-S-003 

Quality  Assurance  for  Space  and  Launch  Vehicles 

13  Jun  08 

Document  No 

Guidance  Title 

Issue 

GAO/N  SI  AD-96- 162 

Best  Practice  Commercial  Quality  Assurance  Practices  Offer 

Improvements  for  DOD 

August  96 

Mil-Hdbk-896 

Manufacturing  and  Quality  Program 

8  Aug  08 

Defense  Acquisition 

DAG,  Chapter  11:  Program  Management  Activities,  Section  11.3  3 

Current  at 

Guidebook  (DAG) 

Quality  Management 

https  ://daq  dau.mil/ 

SMCCPATS 

Critical  Process  Assessment  Tool  -  Quality  Assurance 

6  January  97 

The  QAE  implements  the  relevant  requirements  inherent  hi  the  above  directives  to  facilitate  the  integration  of 
quality  considerations  into  the  engineering,  acquisition,  and  management  processes.  As  part  of  risk  reduction, 
the  QAE  supports  the  PM  to  identify,  eliminate,  and  manage  deficiencies:  the  QAE  provides  support  to 
manage  risks  where  potential  deficiencies  cannot  be  totally  eliminated. 
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QAE  Contributions  to  the  Acquisition  Life  Cycle  Framework 

The  DoD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  QAE  contributions  over  this  life  cycle  are  first 
instituted  duiing  the  acquisition  phase.  QAE  supports  pre  and  post  contract  award  acquisition  activities,  and 
performs  QA  management  and  engineering  across  the  system  lifecycle.  SMC  Program  Offices  establish  and 
implement  QA  program  strategies  and  objectives  consistent  with  appropriate  government  policies,  SMC 
acquisition  objectives,  and  program  objectives.  Using  this  guidance  the  Program  Office  develops,  obtains 
approval  for,  and  implements  QA  planning  into  the  Systems  Engineering  Plan  (SEP)  and  liigher  level 
integrated  planning  (e.g.,  EMP)  in  accordance  with  current  DoD  policy.  Thus  this  planning  is  firmly  based  on 
program  and  technical  objectives,  strategies,  DoD  mandates,  and  ins  Unctions. 

An  effective  QA  program  supports  all  of  the  major  acquisition  activities  through  the  Ml  system  life  cycle. 
DoD  envisions  a  prevention- based  quality  strategy  that  encourages  continuous  improvement  across  the 
industry  by  identifying  the  most  advanced  methods  of  ensuring  quality.  Those  contractors  that  provide 
evidence  of  using  recognized  advanced  QA  concepts  (design  for  manufacturing,  process  control  tecliniques 
sound  relationships  with  key  suppliers,  etc.)  should  be  given  credit  during  a  source  selection  process  {reference 
GAO/NSIAD-96-162  Best  Practices). 

QA  program  planning  to  achieve  vigorous  quality  assurance  and  overall  program  objectives  and  requirements: 
specifies  tasks  and  functions  to  be  performed,  timing  of  tasks,  resources  required,  products  to  be  developed  and 
forms  the  basis  for  the  development  of  the  program  Quality  Assurance  Operating  Instruction  (OI).  The  QA 
plan  and  OI  are  then  reflected  appropriately  hi  the  WBS.  IMS.  and  other  program  documents  that  address  QA 
related  elements.  The  QA  plan  is  executed  concurrently  with  the  Program  Office  OI  that  documents  the  process 
to  perform,  control,  and  integrate  all  quality  assurance  and  management  activities  for  each  phase  of  acquisition. 
The  SMC  Program  Office  QA  planning  (usually  contained  in  the  SEP  and  the  detailed  QA  program  plan)  and 
OI  are  to  be  based  upon  the  appropriate  program-plan  SMC  Program  Offices  appoints  QAE  personnel; 
establishes  and  implements  QA  program  strategies  and  objectives  consistent  with  appropriate  policies,  SMC 
acquisition  objectives,  and  program  objectives. 

1.  Materiel  Solution  Analysis*  During  this  phase  the  QAE 
provides  inputs  to  and  supports  most  program  acquisition 
activities  including  the  development  of  the  acquisition 
strategy,  inputs  to  the  cost  estimates,  solicits tioifRFP 
development  for  Contractor  studies,  and  proposal 
evaluation  activities.  The  QAE  also  contributes  to  the 
development  of  the  MSA  Phase  acquisition  products  by 
specifying  applicable  QA  regulations  and  data  items  such 
as  the  QA  Plan,  QA  inputs  for  the  RFP  development.  QA  prevention  system  and  assessment  requirements, 
and  deficiency  feedback  system  requirements.  The  QAE  contributes  to  Contractor  studies,  evaluates 
alternative  concept  solutions,  and  identifies  deficiencies  and  risks  associated  with  each  concept  solution 
and  proposal  evaluation  activities. 


MSA  Phase  —  SMC  Acquisition  Products 


PMD _ 

ASF,TDS8DMS,TES 

LC  Cost  Estimate _ 

RFP  inputs:  (QA  mission/operational/system 
requirements;  QA  Assessment  requirements) 
APB,  CCA _ 

SSP _ 

QAP,  SEP,  LCMP 
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Figure  9  Acquisition  life  cycle  process  for  SMC  Quality  Assurance  Engineering 
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2.  Technology  Development.  Dining  the  Technology 
Development  Phases  the  QAE  provides  inputs  to  and 
sirpports  and  updates  to  the  cost  model  and  development 
of  the  Cost  Analysis  Requirements  Description  (CARD). 
sohcitation/RFP  development  and  proposal  evaluation 
activities.  Die  QAE  identifies  other  contract  requir  ements 
that  influence  or  impact  product  and  performance  quality 
such  as  incentives/warranty  programs,  quality'  of  design 
requirements  to  meet  QA  objectives:  progress  and  performance  measurements  and  metrics.  The  QAE  also 
contributes  to  the  development  and  updates  to  the  TD  Phase  acquisition  products  as  noted  in  the  table. 
During  tills  phase,  the  QAE  assesses  the  systems,  subsystems,  components,  and  system  operations,  and 
maintenance  concqrts  to  determine  and  address  deficiencies  or  quality  related  risks.  The  QAE  ensures 
reliability,  hazards,  safety,  security  analysis  and  other  analyses  that  indicate  deficiencies  are  completed, 
and  program-unique  risks  are  identified  and  mitigations  implemented  to  eliminate  or  reduce  the  severity  of 
the  risks.  The  QAE  also  ensures  that  the  effectiveness  of  mitigation  measures  is  verified. 


TD  Phase  —  SMC  Acquisition  Pr o ducts 


Updates  to  ASP,  TPS,  QMS _ 

1C  Cost  Estimate  Update  /  CARD  Development _ 

RFP:  QA  objectives  in  the  SQO;  QA  related  tasks  in 
SOW,  QA  data  products  in  CDRLs;  SMC-  QA 
standards  -  tailored _ 

SSP:  evaluation  criteria  for  QA _ 

APB:  QA  objectives  &  related  concept  descriptions 

Detailed  QA  planning,  SEP,  LCMP,  TEMP 


3*  Engineering  &  Manufacturing  Development,  During 
the  EMD  Phase  the  updates  the  cost  model  to  reflect  the 
actual  technical  solutions  determined  and  updates  to  the 
CARD.  The  QAE  supports  the  solicitation/RFP 
development  and  proposal  evaluation  activities  which 
include  providing  the  technical  inputs  including  technical 
QA  requirements.  QA  compliance  standards,  QA 
engineering  and  process  control  approaches,  incentives, 
and  warranty  programs  to  meet  program  objectives.  The 
QAE  also  contributes  to  the  development  and  updates  to 
the  EMD  Phase  acquisition  products  as  noted  in  the  table. 


EMD  Phase  —  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  QMS _ 

CARD  update _ 

RFP:  QA  objectives  in  the  30Gr  QA  related  tasks  in 
SOW,  QA  data  products  in  CDRLs;  SMC-  QA 
standards  -  tailored  QA  program  and  system  quality 
requirements,  Inspection,  cat ibrati on/meteorological, 
audit,  requirements _ 

SSP:  evaluation  criteria  for  QA _ 

APB:  QA  objectives  &  concept  descriptions  that  relate 
toQA _ 

Detailed  QA  Program  Office  and  Contractor  planning, 
SEP,  LCMP,  TEMP  updates 


P*feD  /  O&S  Phase  -  SMC  Acquisition 
Products 


Updates  to  ASP,  TPS,  QMS 


4.  Production  &  Deployment,  Operations  &  Support, 

The  QAE  continues  to  provide  QA  inputs  to  all  program 
acquisition  activities  including  updates  to  the  acquisition 
strategy  and  the  cost  model  to  reflect  the  actual  technical 
solutions,  program  office  decisions,  and  updates  to  the 
CARD  as  the  system  evolves.  The  QAE  supports  the 
sohcitation/REP  development  and  proposal  evaluations. 

The  QAE  identifies  other  contract  requirements: 
production  process  capability  analysis  (hi  conjunction 
with  the  Manufacturing  Engineer),  critical  tests  and 
inspections  requiring  QA  verification.  The  QAE 
formulates  QA  mcentives/warranty  programs;  as  well  as  requirements  for  packaging  and  mspection/test  on 
delivery  of  contracted  items  being  tendered  for  government  acceptance. 


RFP:  QA  objectives  in  the  S00:  QA  related  tasks  in 
SOW,  QA  data  products  in  CDRLs;  SMC-  QA 
standards  -  tailored  QA  program  and  system  quality 
requirements;  Inspection,  caiibration/meteo logical, 
audit,  requirements 


SSP:  evaluation  criteria  for  QA 


Detailed  QA  planning,  SEP,  LCMP,  TEMP  updates 


CARD  update 
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QAE  Contributions  to  the  Engineering  Life  Cycle  Framework 
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Relationship  to  the  SE  Organization 

The  QAE  plans  and  executes  essential  quality  assurance  and  quality  engineering/management  efforts  within 
the  context  and  in  full  support  of  the  overarching  Systems  Engineering  function.  The  QAE  ensures  that  the 
program  QA  planning  is  complete  and  each  QA  SED  contribution  is  timely,  adequate,  consistent,  and 
comp li ant.  The  QAE  ensures  that  their  contributions  are  channeled  through  the  Systems  Engineering  Analyses 
ami  Comrol  activity. 

Systems  Engineers  manage  the  engineering  process  and  activities  depicted  in  Figure  3  while  the  QAE 
contributes  to  this  process.  The  QAE  develops/derives  the  program  specific  QA  requirements  and  supports  the 
requirements  analyses  and  allocations  process.  They  also  participate  hi  technical  studies  and  solutions  trades 
when  quality  assurance  disciplines  are  a  factor.  They  maintain  a  close  liaison  with  the  design  engineers  and 
provide  design  analyses  contributions  to  determine  and  adjust  the  appropriate  level  of  quality  requirements 
through  analyses,  demo,  inspection,  and  test. 

The  QAE  works  closely  with:  System  Engineers  performing  interface  analyses,  functional  analyses,  and  the 
integration,  verification  and  validation  planning  and  execution:  Software  Engineers  to  oversee  software 
development,  they  are  typically  designated  as  Software  Quality  Assurance  (SQA)  or  Software  Quality 
Engineers  (SQE);  the  Reliability  and  Maintainability  (RAM)  Engineer  to  ensure  quality  and  reliability  through 
controlled  and  predictable  quality  levels  dining  production,  handling,  storage,  packaging,  and  transportation. 

hi  performing  the  management  and  control  function,  the  SE  effectively  integrates  all  engineering  functions 
through  the  full  system  life  cycle.  The  QAE  ensures  that  effective  informational  and  statistical  quality 
assurance  techniques  and  advances  are  appropriately  applied  through  systematic  control,  collaboration  and 
sharing  across  the  organization.  For  example,  the  major  quality  system  indicators  i.e.:  Process  Capability 
(Cpk),  Process  Cycle  Efficiency  (the  key  lean  metric).  Cost  of  Quality  (COQ).  MRETs,  FRB's,  Major  Defect 
and  Corrective/  Preventive  Actions,  must  be  routinely  evaluated  and  reviewed  at  Program  Re  views  to  assure 
the  Quality  Program  is  yielding  a  high  level  of  quality  which  is  being  sustained  by  both  acquisition  specialists 
and  contractor  organizations,  me lud mg  subcontractors. 

Relationship  to  other  SEDs 

The  QAE  ensures  their  technical  contribution  to  the  overall  systems  engineering  is  appropriately  applied 
through  systematic  control,  collaboration  and  sharing  across  the  organization.  Since  a  do-it-right-the-first-time 
mindset  must  be  realized  by  all  acquisition  specialists,  the  QAE  works  closely  with  other  specialty  engineers  in 
accomplishing  the  quality  expectations.  In  addition,  the  QAE  products  and  metrics  are  timed  and  applied  by 
the  other  Specialty  Engineers  to  perform  their  unique  contributions,  and  must  be  provided  to  technical  and 
program  management  for  decision  making. 

The  QAE  works  closely  with  the  Manufacturing  Engineer,  and  RAM  Engineer  to  identify  and  assess  process 
and  workmanship  concerns  that  may  potentially  impact  product  quality  and  reliability:  and  to  review7  process 
improvement  opportunities  with  the  contractor. 
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Tools  Selection  and  Use 

The  QAE  evaluates  the  choice  of  QA  tools  for 
effectiveness  and  efficiencies  that  are  used  for  QA 
system  analyses.  T&E,  information  sharing,  automated 
data  exchanges  with  other  tools,  and  other 
considerations. 


Typical  QA  Functions  Requiring  Tools 


Cost  of  Qual  ity  (COQ) _ 

QA  Requirements  Analyses  &  Allocations 
Process  Capability  (Cpk) _ 

Process  Cycle  Efficiency _ 

Major  Defects  Pareto  Chart _ 

Software  Defect  Tracking  System _ 

Correct]  ve/Preventive  Actions 


Engineering  Activities  and  Products  over  the  Life  Cycle 

The  following  subsections  delineate  QAE  contributions  to  engineering  activities  and  technical  products  for 
each  DoD  acquisition  phase.  Refer  to  SMC -S -00 3  for  a  more  complete  description  of  QA  activities  that  are 
performed  by  the  Program  Office  and  their  contractors. 


1. 


2* 


Materiel  Solution  .Analysis*  During  the 
MSA  phase  the  QAE  may  provide  inputs  to 
and  support  the  Capabilities  Based 
Assessment  process  and  the  JCIDS  process. 
The  QAE  also  contributes  to  the 
development  of  the  MSA  Phase  technical 
products  as  noted  in  the  Table. 

Technology  Development*  During  the  TD 
phase  the  QAE  continues  to  provide  inputs 
to  and  supports  the  JCIDS  process.  The 
QAE  also  supports  all  the  engineering 
activities  highlighted  within  the  box  titled 
Engineering  Activities  for  System  <£  Segment 
Development  <£  Desig}}  Figure  9  to 
commence  system  definition  and 
development.  The  QAE  contri  bates  to 


MSA  Phase  —  Technical  Pr  oducts  Required 

SMC  QA  Technical 
Products 

QA  Co nnd buttons  to  Other 
Organi2a  dons T  Prod  a  cts 

High  level  QA  reqJts  analysis 

Operational  Concepts 

QA  inputs  &  factors  for  concept, 
arch  technology  studies^  trades 

AoA  Studies 

QA  System  Req’ts  (draft) 

Initial  Capabilities  Doc  (ICD)  Dev 

Roadmap  inputs  -  mitigations  of 
critical  process  points/  risks 

DoDAF  CVs,  OVs 

TD  Phase  —  Technical  Products  Required 

SMC  QA  Technical 
Products 

QA  Contributions  to  Other 
Organizations1  Products 

Inputs  to  System  Concepts 

Operational  Concepts 

Factors  for  QA  applications 

Operational  Assessments 

QATech  Req’ts,  TRD,  3RD, 
Specifications,  3 CDs,  Standards 
Selection/  Tailor 

Capabilities  Development  Doc 
(CDD) 

PDRs,  CDRs 

QA  inputs  to  ISP 

DoDAF  CVs,  OVs 

QA  Program  Analysis  Reports 

Compliance  Audits 

development  of  the  TD  Phase  technic  a  1  products  as  noted  in  the  Table. 


3*  Engineering  &  Manufacturing 
Development.  The  QAE  continues  to 
provide  inputs  to  and  support  the  JCIDS 
process.  The  QAE  supports  all  the 
engineering  activities  lrighlighted  within  the 
box  titled  Engineering  Activities  for 
Detailed  Design  Figure  9  to  commence 
detailed  systems  definition  and 
development.  The  QAE  establishes  a  closed- 
loop  defect/deficiency  reporting  system 
across  Contractors,  stakeholders  and  other  discrepancy  reporting/analysis  &  collective  action  contributors. 


EMD  Phase  —  Technical  Products  Required 


SMC  QA  Technical 

Pro  ducts 

QA  C  onirihii lions  to  Othei 
Organizations1  Products 

Update  System  Concept 

Operational  Concepts 

Validate  QA  applications 

Operational  Assessments 

QA  System  Tech  Req'ts,  TRD, 
SRD,  Spec,  ICDs 

Capabilities  Production  Doc 
(CPD) 

Inputs  to  system,  production, 
fielding,  sustain  design  docs 

Mfg  Readiness  Reviews,  Test 
Readiness  Reviews 

QA  inputs  to  ISP 

DoDAF  CVs,  OVs 

QA  Program  Analysis  Reports 

Compliance  Audits 

Process  Capability  Reports 

Contractor  assessments 
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The  activities  of  the  Q AE  dining  this  phase  are  extensive.  Refer  to  the  SMC-S-003  QA  Guide  for  QAE 
activities  and  products  typically  required  during  each  phase.  The  QAE  develops  and  contributes  to  the 
development  of  the  EMD  Phase  technical  products  to  assure  a  high  level  of  manufactured -in  quality. 

4.  Production  &  Deployment,  Operations  & 

Support*  The  QAE  continues  to  provide 
inputs  to  and  supports  the  JCTDS  process 
during  the  P&D/O&S  phase.  The  activities 
of  QA  during  this  phase  are  extensive.  Refer 
to  the  SMC-S-003  Quality  Assurance  Guide 
for  QA  activities  and  products  typically 
required  during  each  phase.  The  QAE 
dev  elops  and  contributes  to  the  development 
of  the  P&D  /  O&S  Phase  technical  products 
as  noted  in  the  Table. 

QAE  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  then  business  model  and  approach  structure  based  primarily  on  the  unique  aspects 
of  each  project.  These  factors  include:  program  objectives,  program  and  technical  challenges,  organizational 
structure,  as  well  as  program  and  engineering  planning  (SEP  plus  detailed  RAM  planning). 

The  QAE  develops  and  implements  the  QA  program  plan  to  achieve  QA  objectives  and  requirements.  The 
planning  defines  the  QA  tasks  and  functions  to  be  performed  and  products  to  be  developed:  tuning  of  tasks, 
task  outputs,  resources  (skills,  tools,  equipment),  and  completion  criteria.  The  QAE  plans  tasks  to  integrate  QA 
activities  within  the  program  office,  between  Contractors  and  stakeholders.  The  QAE  plans  the  tasks  to 
establish  and  manage  the  QA  program:  support  SE&I  activities,  e.g.,  production  process  controls,  V&V 
activities,  risk  management,  integration,  system  modifications,  contractor  compliance  verification 
requirements:  coordinate  the  QA  planning  with  the  SMC  QA  OPR.  operating  commands,  supporting 
commands,  and  test  agencies:  and  integrate  QA  planning  with  other  functional  and  acquisition  plans  (i.e.  SEP, 
ASP,  LCMP). 

Execution  of  the  QA  plan  is  typically  defined  through  an 
Operating  Instruction  (01).  The  QAE  provides  full  support  to 
define  the  program  and  technical  objectives  where  quality" 
assurance  and  engineering  should  be  applied.  The  QAE  assists 
to  establish  the  business  model  dev  elop  program  planning 
and  schedules,  and  define  and  implement  program  processes. 

The  QAE  ensures  the  QA  components  of  the  program  are  appropriately  represented  in  the  program  plans, 
program  schedules,  work  breakdown  schedules,  and  cost  estimates.  The  QAE  also  reports  their  assigned 
program's  technical  performance  and  progress.  The  QAE  supports  the  program  manager's  problem 
identification,  resolution,  and  decision-making  processes  by  providing:  program  quality  performance 
assessments,  contractor  cost  of  quality  and  deficiency  identification  reports  and  assessments  as  available, 
evaluations  of  contractor  and  DCMA  system  audit  results,  preparing  and  executing  Program  Office/DCMA 


SMC  Program  Management  Products 


PMD _ 

SEP,  IMF,  fMS,WBS _ 

Decision-making  &  problem  solving  inputs 

Technical  progression  and  issues  reporting 

LC  Cost  Estimate  (CARDs) _ 

Processes  (01s) _ 

Risk  Management  Inputs 


P&D  /  O&S  Phase  -  Technical  Products  Required 


SMC  QA  Technical 
Products 

QA  Contributions  to  Other 
Organizations-  Products 

Inputs  to  tech  baseline/ 
engineering  changes 

Supportabitity  Analyses  Rpt 

Analyses  of  production  quality 
reports  and  test  reports 

Operational  Assessments 

Hardware  Acceptance  Reviews 

Transition  &  Fielding  Docs 

Logistics  Reports 

QA  Analyses  Reports;  Process 
capability  &  cycle  efficiency 
reports 

Management  System  Reviews 

COQ  Reports 

Financial  Assessments 
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MOAs  and  maintaining  interaction  with  contractor  QA  Management  and  DCMA  QA  personnel.  Tire  QAE 
contributes  QA  inputs  for  the  development  of  the  program  management  products  identified  in  the  Table. 
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Appendix  G  -  Reliability,  Availability  and  Maintainability 

The  SMC  Program  Office  Reliability,  Availability  &  Maintainability  (RAM)  Engineers  have  the  responsibility 
to  stand-up  and  execute  the  RAM  program.  The  RAM  Engineer  plans  and  executes  the  essential  RAM 
engineering  and  management  efforts  in  an  integrated  and  effective  manner  to  ensure  that  each  RAM  SED 
contribution  is  timely,  adequate,  consistent,  and  compliant.  The  RAM  Engineer  ensures  that  their  contributions 
are  channeled  through  the  Systems  Engineering  Analyses  and  Control  activity. 


Applicable  governance,  standards,  and  guidance 

Policy,  directives,  and  instructions  that  mandate  RAM  engineering  related  program  requirements  are  included 
in  a  wide  range  of  mandates  including  those  providing  requirements  for  acquisition.  T&E,  software.  Systems 
Engineering*  and  others.  Table  12  below  identifies  the  significant  governance,  standards,  and  guidance  which 
generally  requite  SMC  compliance  for  RAM. 

Table  12  Governance,  standards,  and  guidance  tliat  shape  the  RAM  engineering  discipline 


Document  No 

Governance  Title 

Issue 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

CJCSM  3170.01 

Operation  of  the  Joint  Capabilities  integration  and  Development  System 

24  Jun  03 

AF1 10-601 

Capabilities  Based  Requirements  Development 

30  JuE  04 

AFI 21-108 

Maintenance  Management  of  Space  Systems 

25  Jut  94 

AFI21-118 

Improving  Air  and  Space  Equipment  RAM 

02  Oct  03 

AFf  63-1201 

Life  Cycle  Systems  Engineering 

23  Jul  07 

SMCI  62-001 

Reliability  And  Maintainability 

11  Apr  07 

Document  No 

Standards  Title 

Issue 

SMC-S-013 

Reliability  Program  For  Space  Systems 

13  Jun  08 

Mii-Std-785B 

Reliability  Program  For  Systems  And  Equipment  Development  And 
Production 

03  Jul  86 

Document  No 

Guidance  Title 

Issue 

DoD  Guide  For  Achieving  Reliability,  Availability,  And  Maintainability 

03  Aug  05 

DoD  Reliability,  Availability,  Maintainability,  Cost  Rationale  Report 
Manual 

01 Jun  09 

MIL-HDBK-217 

Reliability  Prediction  of  Electronic  Equipment 

28  Feb  95 

CPATS 

Critical  Process  Assessment  Tool  -  Reliability  Engineering 

14  Aug  98 

RAIC 

Rome  Laboratory  Reliability  Engineer's  Toolkit 

Apr  93 

RAM  Engineers'  Contributions  to  the  Acquisition  Life  Cycle  Framework 

The  DoD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  ELAM  Engineer  contributions  over  this  life  cycle 
are  best  represented  within  the  phase  of  acquisition.  Figure  1 0  prorides  the  acquisition  life  cycle  framework 
within  wliicli  FLAM  Engineers  perform  as  well  as  the  products  that  the  FLAM  Engineers  must  develop  or 
contribute  to  then  development.  This  figure  along  with  SMCI  62-001,  Sections  4  and  5  requirements  to 
perform  FLAM  plauning,  support  pre  and  post  contract  award  acquisition  activities,  and  perform  RAM 
management  and  engineering  across  the  system  lifecycle.  SMC  Program  Offices  establish  and  implement 
RAM  program  strategies  and  objectives  consistent  with  the  tenets  of  appropriate  policies,  SMC  acquisition 
objectives,  and  program  objectives.  The  Program  Office  then  develops,  attains  approval  for,  and  implements 
RAM  planning  into  the  Systems  Engineering  Plan  (SEP)  and  higher  level  integrated  planning  (e.g.,  IMP)  in 
accordance  with  current  DoD  policy.  This  plauning  is  firmly  based  on  program  and  teclinical  objectives, 
strategies,  DoD  mandates,  and  instructions. 
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An  effective  RAM  program  supports  all  of  the  major  acquisition  activities  through  the  hill  system  life  cyde. 
The  planning  sufficiently  defines  the  RAM  program  to  achieve  the  RAM  and  overall  program  objectives  and 
requirements;  specifies  tasks  and  functions  to  be  performed,  timing  of  tasks,  resources  required,  products  to  be 
developed,  and  forms  the  basis  for  the  development  of  the  program  RAM  Operating  Instruction  (OI).  The 
RAM  planning  and  OI  are  then  reflected  appropriately  in  the  WBS,  IMS,  and  other  program  documents  that 
address  RAM  related  elements.  The  RAM  planning  is  executed  concurrently  with  the  Program  Office  OI  that 
documents  the  process  to  perform,  control,  and  integrate  all  RAM  engineering  and  management  activities  for 
each  phase  of  acquisition.  The  SMC  Program  Office  RAM  planning  (usually  contained  in  the  SEP  and  the 
detailed  RAM  program  planning)  and  OI  are  be  based  upon  the  appropriate  program -approved  life  cycle.  SMC 
Program  Offices  appoint  establish  and  implement  RAM  program  strategies  and  objectives  consistent  with  the 
tenets  of  appropriate  policies,  SMC  acquisition  objectives,  and  program  objectives. 

1 .  Materiel  Solution  Analysis.  During  this  phase  the  RAM 
Engineer  provides  inputs  to  and  supports  most  program 
acquisition  activities  to  include  the  development  of  the 
acquisition  strategy,  inputs  to  cost  estimates, 
solicitation/RPP  development  for  Contractor  studies,  and 
proposal  evaluation  activities.  The  RAM  Engineer  also 
contributes  to  the  development  of  tlie  MSA  Phase 
acquisition  products. 


MSA  Phase  —  SMC  Acquisition  Products 


RAM-C  Report  (Attached  to  AoA) _ 

ASP,  TDS:  DMS,  TES  _ 

LC  Cost  Estimate _ 

RFP  inputs  (RAM  mis  sion/operational/  system 
requirements;  RAM  Assessment  requirements;  High 
level  reliability  formulations _ 

APB,  CCA _ 

SSP,  SEP 


2.  Technology  Development.  The  RAM  Engineer  provides 
inputs  to  and  supports  all  program  acquisition  activities  to 
include  the  development  of  the  acquisition  strategy, 
updates  to  the  cost  model  and  development  of  the  Cost 
Analysis  Requirements  Description  (CARD) 
solicitation/RFP  development  and  proposal  evaluation 
activities.  Tlie  RAM  Engineer  identifies  other  contract 
requirements  such  incentives/warranty  programs  and  test 
&  demo  requirements  to  meet  RAM  objectives.  The  RAM 
and  updates  to  the  TD  Phase  acquisition  products. 


TD  Phase  —  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  QMS,  LCSP  with  RAM-C 


LG  Cost  Estimate  Update  /  CARD  Development _ 

RFP:  RAM  objectives  in  the  SOO;  RAM  related  tasks 
in  SOW,  RAM  data  products  in  CDRLs;  SMC-  RAM 
standards  -  tailored 


SSP:  evaluation  criteria  for  RAM 


APB:  RAM  objectives  &  related  concept  descriptions 
Detailed  RAM  planning,  SEP,  TEMP 


Engineer  also  contributes  to  the  development 


Engineering  &  Manufacturing  Development.  Tlie 


EMD  Phase  —  SMC  Acquisition  Products 


RAM  Engineer  provides  inputs  to  and  supports  ail 
program  acquisition  activities  to  include  updates  to  the 
acquisition  strategy  and  updates  to  tlie  cost  model  to 
reflect  tlie  actual  technical  solutions  determined  and 
updates  to  the  CARD.  RAM  Engineer  supports  the 
solicitation/RPP  development  and  proposal  evaluation 
activities  which  include  providing  the  technical  inputs 
including  te clinical  requirements,  compliance  standards,  engineering  approaches,  incentives,  and  warranty 


Updates  to  ASP,  TPS,  QMS,  LCSP  with  RAM-C 
CARD  update _ 

RFP:  RAM  objectives  in  the  SOO;  RAM  related  tasks 
in  SOW,  RAM  data  products  in  CDRLs;  SMC-  RAM 
standards  -  tailored _ 

SSP:  evaluation  criteria  for  RAM _ 

APB:  RAM  objectives  &  related  concept  descriptions 

Detailed  RAM  planning,  SEP,  TEMP  updates 


programs  to  meet  program  objectives.  The  RAM  Engineer  identifies  other  contract  requirements  such 


incentives,' warranty  programs  and  prototype  and  engineering  qualification  unit  reliability  related  test  & 
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requirements  to  meet  RAM  objectives.  RAM  Engineer  also  contributes  to  the  development  and  updates  to 
the  RMD  Phase  acquisition  products. 

4.  Production  &  Deployment*  Operations  &  Support* 

The  RAM  Engineer  provides  inputs  to  and  supports  all 
program  acquisition  activities  to  include  updates  to  the 
acquisition  strategy  and  updates  to  the  cost  model  to 
reflect  the  actual  technical  solutions  determined  and 
updates  to  the  CARD.  RAM  Engineer  supports  the 
solicitation/RPP  development  and  proposal  evaluation 
activities.  The  RAM  Engineer  identifies  other  contract 
requirements:  incentive  s/warranty  programs;  production 
performance  and  sustainment  analyses  to  meet  RAM  objectives. 


P&D  /  O&S  Phase  -  SMC  Acquisition 
Products 


Updates  to  ASP,  TPS,  DMS,  LCSP  with  RAM-C 
RFP:  RAM  objectives  in  the  S00;  RAM  related  tasks 
in  SOW,  RAM  data  products  in  CDRLs;  SMC-  RAM 
standards  -  tailored _ 

SSP:  evaluation  criteria  for  RAM _ 

Detailed  RAM  planning,  SEP,  TEMP  updates _ 

CARD  update _ 

and  field  test  &  demo  requirements:  field 
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Figure  10  Acquisitiou  life  cycle  process  for  SMC  RAM  Eugineering 
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leal  Data  among 
tekeholdera 


Assess  Contractors'  fl  Subs  Compliance  to  R&M 
Require  ments 


Assess  Allocations  A  Predictions 


Assess  Adequacy  of  FMEA,  FTA,  Life,  olher 
Reliability  Analyses  £  Contractors'  Effectiveness 
to  Design  for  R&M 


Assess  FRACAS,  and  FRB  Programs 


Assess  Contractors3  V&U  Procedures  &  Results: 
Analyses,  Teste,  Demos 


r 

C) 

>H0 

Disseminate  R£M 

Technical  Data 

y — i ► 

auTtonq  Stakeholders 

■Assess  Contractors'  Compliance  to  Req'ts 


Assess  Adequacy  of  Lot  Qua!,  Acceptance,  &  Other 
Testing  to  Provide  Reliability  Ver 


Review  Contractors'  Tech  Data  (Tedimca!  &  Trailing 
Manuals,  Specs.  Drawings,  Test  £  Integration 
Procedures 


Assess  R£M  Test/Demo  Procedures,  Results 


Assess  FRACAS,  and  FRB  Programs 


Ensure  Contractors'  PMP  Program  is  Integrated  wflh 
R£M  and  ILS  Programs 


>►© 


Disseminate 
RSMTsch 
Data  among 
Stakeholders 


102 


RAM 


SMC  Specialty  Engineering  Disciplines 

RAM  Engineers'  Contributions  to  the  Engineering  Life  Cycle  Framework 

Relationship  to  the  SE  Organization 

The  RAM  Engineer  plans  and  executes  essential  RAM  engineering  and  engine ering  management  efforts  in  an 
integrated  and  effective  manner  witlrin  the  context  and  hill  support  of  the  overarching  Systems  Engineering 
function.  The  RAM  Engineer  ensures  that  each  RAM  SED  contribution  is  timely,  complete,  consistent,  and 
compliant.  The  RAM  Engineer  ensures  that  their  contributions  are  channeled  through  the  Systems  Engineering 
Analyses  and  Control  activity.  Systems  Engine ers  manage  the  engineering  process  and  activities  depicted  hi 
Figure  3  while  the  RAM  Engmeer  contributes  to  tliis  process.  The  RAM  Engineer  supports  concept  and 
architecture  development  and  analyses;  modeling  and  simulation  efforts  and  technology  studies.  The  RAM 
Engmeer  develops/derives  their  requirements  and  supports  the  requirements  analyses  and  allocations  process. 
They  also  participate  hi  technical  studies  and  solutions  trades  when  reliability  and/or  maintainability  are  a 
factor.  They  provide  design  analyses  contributions  to  determine  and  validate  reliability  allocations,  update 
reliability  predictions,  and  ensur  e  confidence  in  attaining  RAM  requirements  through  analyses,  demo,  and  test. 

The  RAM  Engmeer  also  works  closely  with  the  System  Engineers  performing  interface  analyses,  functional 
analyses,  and  the  integration  and  verification  and  validation  planning  and  execution.  The  Reliability  Engineer 
works  closely  with  the  Logistics  Engineers  performing  maintenance  and  sustainment  analyses.  The  Reliability 
Engineer  aligns  closely  with  the  Quality  Assurance  and  Quality  Engineer  to  ensure  reliability  tlnough 
controlled  and  predictable  quality  levels  during  production,  handling,  storage,  packaging,  and  transportation. 

In  performing  the  management  and  control  function,  the  SE  effectively  Late  grates  all  engrne  ering  functions 
through  the  full  system  life  cycle.  The  RAM  Engmeer  ensures  then  technical  information  advances  and  is 
appropriately  applied  through  systematic  control,  collaboration  and  sharing  across  the  organization.  For 
example,  their  analytical  products  (e.g.,  fault  tree,  failure  modes,  critical  items  lists,  reliability  block  diagrams, 
etc)  must  be  timed  and  applied  by  die  other  Specialty  Engineers  to  perform  their  unique  contributions,  and 
must  be  provided  to  technical  and  program  management  for  decision  making. 

Relationship  to  other  SEDs 

The  RAM  Engineer  ensures  their  technical  contribution  to  the  overall  engineering  advances  and  is 
appropriately  applied  through  systematic  control,  collaboration  and  sharing  across  the  organization.  For 
example,  their  failure  analysis  products  are  timed  to  coincide  with  hazards  analyses,  HSI  analysis,  architectural 
trades,  design  trades,  and  supportability  analysis.  In  addition  the  RAM  Engineers  products  are  timed  and 
applied  by  the  other  Specialty  Engineers  to  perform  their  unique  contributions,  and  must  be  provided  to 
technical  and  program  management  for  decision  making. 

The  RAM  Engineer  works  closely  with  the  Logistics  Engineers  to  determine  maintenance  needs  for  system 
elements  prone  to  failures.  The  RAM  Engineer  works  closely  with  QAQE  specialists  to  identify  and  assess 
process  and  workmanship  concerns  that  may  potentially  impact  system  reliability. 
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Tools  Selection  and  Use 
The  RAM  Engineer  considers  effectiveness  and 
efficiencies  gained  by  selecting  and  using  the 
best  choice  of  RAM  tools  considering  the  RAM 
tool  requirements  possibly  tor  RAM 
formulations,  modeling,  predictions,  reliability 
analyses.  T&E.  information  sharing,  automated 
data  exchanges  with  other  tools,  and  other 
considerations. 

Engineering  Activities  and  Products  over  the  Life  Cycle 

The  following  subsections  delineate  RAM  contributions  to  engineering  activities  and  technical  products  by 
DoD  acquisition  phase.  Refer  to  SMC-G-002  for  a  more  complete  list  of  RAM  Engineering  activities  and 
products  that  are  prepared  by  the  Program  Office  and  then  Contractors. 

1.  Materiel  Solution  Analysis*  Dining  this 
phase  the  RAM  Engineer  may  provide 
inputs  to  and  support  the  Capabilities  Based 
Assessment  process  and  the  JCIDS  process. 

The  RAM  Engineer  also  contributes  to  the 
development  of  the  MSA  Phase  te clinical 
products. 


MSA  Phase  —  Technical  Products  Required 


SMC  RAM  Technical 
Products 

Contributions  to  Other 
Organizations'  Products 

High  level  reliability  analysis 

Operational  Concepts 

RAM  inputs  and  factors  for 
concept,  architecture,  technology 
studies,  and  trades 

AoA  Studies 

System  RAM  Reefs  (draff) 

initial  Capabilities  Doc  (ICD)  Dev 

Roadmap  inputs  -  mitigations  of 
RAM  nsks 

DoDAL  CVs,  OVs 

Typical  RAM  Functions  Requiring  Tools 


Modeling  &  Predations _ 

RAM  Requirements  Analyses  &  Allocations _ 

Experiment  Design,  Growth,  and  Life  Data  Analysis _ 

Accelerated  Life  Testing;  System  Analysis:  RBDs  &  Fault  Trees 

Reliability  Centered  Maintenance _ 

LMEA 


2.  Technology  Development.  During  this  phase  the  RAM  Engineer  continues  to  provide  inputs  to  and 
supports  the  JCIDS  process.  The  RAM 
Engineer  also  supports  ail  the  engineering 
activities  highlighted  within  the  box  titled 
Engineering  Ac th  iries  for  S\  \s  ten  i  <£  Segjf  i  en  t 
Development  A  Design  Figure  10  to 
conunence  system  definition  and 
development.  RAM  Engineer  develops  and 
contributes  to  development  of  the  TD  Phase 
technical  products. 


TD  Phase  —  Technical  Products  Required 


SMC  RAM  Technical 
Products 

Contributions  to  Other 
Organizations'  Products 

Inputs  to  System  Concepts 

Operational  Concepts 

Factors  for  Studies/  Trades 

Operational  Assessments 

RAM  Tech  Req’fs,  TRD,  SRD, 
Specif  cations,  ICDs,  Standards 
Selection/  Tailor 

Capabilities  Development  Doc 
(ODD) 

RAM  inputs  to  ISP 

DoDAF  CVs,  OVs 

RAM  Analyses  Rpts 

RAM 
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3.  Engineering  &  Manufacturing 
Development,  RAM  Engineer  continues  to 
provide  inputs  to  and  support  the  JCIDS 
process.  Tlie  RAM  Engineer  supports  all  the 
engineering  activities  Iiighlighted  within  the 
box  titled  Engineering  Activities  for 
Detailed  Design  Figure  10  to  commence 
detailed  systems  definition  and 
development.  Hie  RAM  Engineer 
establishes  a  closed -loop  failure  reporting 
system  across  Contractors,  stakeholders  and 
other  failure  reporting/analysis  &  collective  action  contributors.  The  RAM  Engineer  establishes  JRMET 
to  assist  in  collecting,  analyzing,  and  categorizing  RAM  data  during  DT&E  inputs  to  and  supports  the 
JCIDS  process.  The  activities  of  RAM  during  this  phase  are  extensive.  Refer  to  the  SMC  -G-002  RAM 
Guide  for  RAM  Engineer  activities  and  products  typically  required  during  each  phase.  RAM  Engineer 
develops  and  contributes  to  the  development  of  the  EMD  Phase  technical  products. 

4.  Production  <&  Deployment,  Operations  & 

Support.  RAM  Engineer  continues  to 
provide  inputs  to  and  supports  the  JCIDS 
process.  The  activities  of  RAM  during  this 
phase  are  extensive.  Refer  to  the  SMC-G- 
001  RAM  Guide  for  RAM  Engineer 
activities  and  products  typically  required 
during  each  phase.  Tlie  RAM  Engineer 
develops  and  contributes  to  the  development 
of  the  P&D  /  O&S  Phase  technical  products. 

RAM  Engineers’  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  then  business  model  and  approach  structure  based  primarily  on  their  program 
objectives,  program  and  technical  challenges,  organizational  structure,  as  well  as  program  and  engineering 
planning  (SEP  plus  detailed  RAM  planning). 

The  RAM  Engineer  develops  and  implements  the  ELAM  program  planning  to  achieve  RAM  objectives  and 
requirements.  The  planning  defines  the  RAM  tasks  and  functions  to  be  performed  and  products  to  be 
developed:  timing  of  tasks,  task  outputs,  resources  (skills,  tools,  equipment,  and  completion  criteria.  Tlie  ELAM 
Engineer  plans  tasks  to  integrate  RAM  activities  within  tlie  program  office,  between  Contractors  and 
stakeholders.  Tlie  RAM  Engineer  plans  the  tasks  to  establish  and  manage  the  JRMET.  FRACAS,  and  other 
RAM  related  forums:  support  SE&I  activities,  e.g.,  production  process  controls,  V&V  activities,  risk 
management,  integration,  and  system  modifications:  coordinate  the  RAM  planning  with  SMC  RAM  Official 
Person  Responsible  (OPR),  operating  commands,  supporting  commands,  and  test  agencies:  and  integrate  RAM 
planning  with  other  functional  and  acquisition  plans  (i.e.  SEP,  ASP,  LCMP). 


P&D  /  O&S  Phase  -  Technical  Products  Required 


SMC  RAM  Technical 
Products 

RAM  Contributions  to 
Other  Organizations’ 
Products 

Inputs  tech  baseline  engineering 
changes 

Sup  portability  Analyses  Rpt 

Analyses  of  production  quality 
reports  and  test  reports 

Operational  Assessments 

Transition  &  Fielding  Docs 

RAM  Analyses  Rpts;  Reliability 
And  Maintainability  Information 
System  Assessments  (REMIS) 

V&V  /T&E  Reports 

EMD  Phase  -  Technical  Products  Required 


SMC  RAM  Technical 

Products 

Contributions  to  Other 
Organizations’  Products 

Update  System  Concept 

Operational  Concepts 

Technical  Studies/  Trades 

Operational  Assessments 

System  Tech  ReqJts,  TRD,  SRD, 
Spec,  ICDs;  RAM  allocations 

Capabilities  Production  Doc 
(CPD) 

Inputs  to  system,  production, 
fielding,  sustain  design  docs 

RAM  inputs  to  ISP 

DoDAF  CVs,  OVs 

RAM  Analyses  Rpts,  RBD, 
models,  predictions 

Test,  Demo  reports 
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Execution  of  the  RAM  planning  is  typically  defined  through  an  Operating  Instruction  (01).  The  RAM 
Engineer  provides  full  support  to  define  the  program  and  technical  objectives  where  RAM  challenges  and  risks 
are  known  or  anticipated.  The  RAM  Engineer  assists  to  establish  the  business  model,  develop  program 
planning  and  schedules,  and  define  and  implement  program  processes.  The  RAM  Engineer  ensures  the  RAM 
components  of  the  program  are  appropriately  represented  in  the  program  plans,  program  schedules,  work 
breakdown  schedules,  cost  estimates.  The  RAM  Engineer  also  reports  then  technical  performance  and 
progress.  The  RAM  Engineer  shares  in  the  risk  management  responsibilities  to  identify,  assess,  and  propose 
mitigating  actions  of  RAM  related  risks.  They  also  support  the  program  manager's  problem  identification, 
resolution,  and  decision-making  processes. 

The  RAM  Engineer  contributes  to  the  development  of  the 
program  management  products  identified  in  the  Table. 


SMC  Program  Management  Products 


PMD 


SEP,  IMP,  IMS  WBS 


Decision-making  &  problem  solving  inputs 


Technical  progression  and  issues  reporting 


LC  Cost  Estimate  (CARDs) 


Processes  (OEs) 


Risk  Management  inputs 
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Spec  mini 


Appendix  H  -  Spectrum  Management 

Spectrum  Management  (SM)  is  that  discipline  that  pertains  to  the  planning,  engineering,  administration  and 
coordination  for  the  joint  use  of  the  range  of  frequencies  of  electromagnetic  (EM)  radiation  by  subsystems  and 
equipment  that  radiate  or  receive  EM  energy.  This  range  of  frequencies,  which  is  divided  into  26  alphabetical 
bands,  is  a  natural  resource  witlhn  national  and  international  boundaries.  Advances  in  modern  technologies  in 
recent  years  and  a  shift  in  joint  war  fighting  strategies  have  demonstrated  a  proliferation  of  potential  conflicts 
resulting  from  the  increased  use  of  the  EM  spectrum  by  both  government  and  non -government  users.  As  a 
result,  the  requirement  for  proper  analyses  and  management  of  the  use  of  the  spectrum  has  risen  exponentially 
in  response  to  the  increasing  demand  for  its  application. 

The  SMC  Program  Office  SM  POC  is  the  designated  authority  responsible  for  establislihig  and  executing  the 
SM  program.  A  SM  POC  is  an  individual  appointed  as  the  representative  of  the  Program  Office  to  manage  its 
affairs.  The  SM  POC  is  also  responsible  for  planning,  administering  and  ensuring  essential  SM  engineering 
and  management  efforts  are  integrated  with  the  various  acquisition,  management,  &  engineering  activities.  In 
addition,  the  SM  ensures  adherence  to  effective  and  compliant  contributions  with  respect  to  the  various 
policies,  DoD  mandates,  instructions,  and  SMC  acquisition  program  and  teclmical  objectives,  while 
implementing  the  program  strategies  and  plans  witlihi  the  POC's  realm  of  responsibilities. 

Applicable  governance,  standards,  and  guidance 

SM  related  program  requirements  are  delineated  throughout  a  broad  range  of  mandates  including  public  law, 
policies,  directives,  and  instructions.  These  requisite  requirements  also  interrelate  with  various  disciplines 
including  acquisition,  information  assurance,  and  Systems  Engineering  to  name  a  few.  Table  13  below 
identifies  the  significant  governance  which  generally  requires  SMC  compliance  for  SM.  At  the  time  of  tliis 
writing,  an  SMC  Ins  Unction  is  in  progress  to  more  clearly  promulgate  the  scope,  responsibilities,  procedures 
and  requirements  of  the  SM  office  as  it  pertains  to  the  various  acquisition,  management  and  engineering 
life  cycles. 

Table  13  Govern  a  uce«  standards,  and  guidance  that  shape  tbe  Spectrum  Management  Engineer  lug  Discipline 


Document  No 

Governance  Title 

Issue 

Public  Law  Number  416, 
Ch  5,Title  47  of  US  Code 

The  Communications  Act  of  1 934 

19  Jun  34 

Public  Law  102-538, 106 
Stat.  3533  (codified  at  47 
U.S.C  901  etseq.) 

The  National  Telecommunications  and  Information  Organization  Act, 

'  Spectrum  Management  Activities" 

92 

DoD  Net-Centric  Spectrum  Management  Strategy 

03  Auq  06 

DoDD  5000.01 

The  Defense  Acquisition  System 

12  May  03 

OoDD  5100.35 

Military  Communications-Efectronics  Board  (MCEB) 

10  Mar  98 

DoDD  4630.8 

Procedures  for  Interoperability  &  Supportability  of  Information 
Technology  (IT)  and  National  Security  Systems  (NSS) 

30  Jun  04 

DoDD  3222.3 

DoD  Electromagnetic  Environmental  Effects  (E3)  Program 

08  Sep  04 

DoD!  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

DoDI  4650.1 

Policy  and  Procedures  for  the  Management  and  Use  of  the 
Electromagnetic  Spectrum 

09  Jan  09 

CJCSM  3170.01 

Operation  of  the  Joint  Capabilities  Integration  and  Development 
System 

01  May  07 

CJCSI 621 2.01  E 

Interoperability  and  Supportability  of  information  Technology  and 
National  Security  Systems 

15  Dec  08 
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NTIA  Manual 

Department  of  Commerce  (DoC)  National  Telecommunications  and 
Information  Administration  (NTIA)  Manual  of  Regulations  and 
Procedures  for  Federal  Radio  Frequency  Management 

May  10  (Revision) 

AFPD 16-2 

Disclosure  of  Military  Information  to  Foreign  Governments  and 
international  Organizations 

10  Sep  93 

AFPD33-1 

Information  Resources  Management 

27  dun  06 

AFPD  61-2 

Management  of  Scientific  and  Technical  Information 

07  Apr  93 

AF1 10-707 

Spectrum  Interference  Resolution  Program 

20  Jun  05 

AFI 31401 

Information  Security  Program  Management 

01  Nov  05 

AFI 33-106 

Managing  High  Frequency  Radios,  Personal  Wireless 

Communication  Systems,  And  The  Military  Affiliate  Radio  System 

09  Jan  02 

AFI  33-1 18 

Electromagnetic  Spectrum  Management 

18  Jul  05 

OMB  Circular  A-11 

Preparation,  Submission  and  Execution  of  The  Budget 

Aug  09 

ITU  Radio  Regulations 

04 

Document  No 

Standards  Title 

Issue 

Mil-Std449D  1 

Radio  Frequency  Spectrum  Characteristics  Measurement  of 

22  Feb  93 

MIL-STD461F 

Electromagnetic  Emissions  and  Susceptibility,  Requirements  for  the 
Control  of  Electromagnetic  Interference 

10  Dec  07 

Mil-Std464A 

Electromagnetic  Environmental  Effects  Requirements  For  Systems 

19  Dec  02 

Document  No 

Guidance  Title 

Issue 

Allied  Communications 

Pub  190C,  US.  Sup  1 

Guide  to  Spectrum  Management  in  Military  Operations 

Sep  07 

DAG,  Chapter  76 

The  Defense  Acquisition  Guidebook,  The  Electromagnetic  Spectrum 

05  May  10 

AFMAN  33-120 

Electromagnetic  Spectrum  Management 

19  Sep  06 

MIL  HD8K-237C 

Electromagnetic  Environmental  Effects  and  Spectrum  Sup  portability 
Guidance  For  The  Acquisition  Process 

20  May  05 

With  regards  to  advancements  in  technological  innovations  and  rising  demand  for  the  use  of  the 
electromagnetic  spectrum  from  new  technologies  such  as  wireless  systems,  the  SM  concept  complies  with 
classic  economic  principles.  The  rise  in  demand  results  in  a  decline  of  supply  and  vice  versa.  In  other  words, 
more  systems  occupying  real  estate  on  the  frequency  spectrum  results  in  less  space  availability  for  additional 
systems  to  operate  within  the  spectrum.  Therefore,  in  reference  to  the  military,  SM  practices  should  be  given 
critical  consideration  in  the  development  and  operation  of  a  variety  of  spectrum  dependent  military 
communications  and  satellite  systems.  Ultimately,  failure  to  properly  manage  this  can  significantly  impact  the 
military's  mission  effectiveness. 


Spectrum  Management  Contributions  to  the  Acquisition  Life  Cycle 
Framework 

Although,  SM  contributions  to  the  DoD  acquisition  life  cycle  appear  less  visible  than  the  contributions  and 
requirements  of  other  functional  disciplines  as  outlined  in  DoDI  5000.02.  it  certainly  remains  a  vital  ingredient 
to  the  success  of  The  entire  mission  accomplishment.  As  with  other  Systems  Engineering  Disciplines  (SEDs), 
SKI  contributions  can  be  dearly  represented  within  the  phases  of  acquisition.  Figure  1 1  outlines  the  activities 
and  products  that  must  be  developed  with  regards  to  the  acquisition  hfe  cycle  framework.  This  graphical 
representation  provides  the  SM  POC  with  a  bird's  eye  dew  of  how  SM  integrates  within  the  acquisition  life 
cycle  framework.  It  also  illustrates  the  required  SM  support  for  pre  and  post  contract  award  acquisition 
activities  as  well  as  across  the  system  lifecycle. 
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Acquisition  Life-Cycle  Process  for  Spectru 


Mate  rial  Solution  Analysis 


Technology  Development 
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Identify  SM  Tasks  ft  Turning  of 
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Support  CB  A: 

1)  Provide  SM 
Performance  and 
Constraints  (if 
known) 

2)  Define  ft  Assess 
SM  Capability  Gaps 
and  Constraints, 
Assess  Mission 
Models  ft  SM 
related  MQPs 

3)  Provide/  Assess 
Alternative  SM 
Approaches  Co 
Solve  Gaps 
Identified  in  CBA 


Support  ICD  Development 
ft  Updates 


Assess  Concepts  for 
Consistency  with  Known 
Capabilities  Constraints 


Identify  SM  ConstraintE  lor 
Each  Proposed  Concept 


Identify  and  Plan 
Mitigations  oTSM  Risks 


Engineering  Activities  for  System  and  Subsystem  Dev  ft  Design 


Participate  in  AtlA  Studies, 
Support  determinations  of 
FOMs.  Characterize  Candidate 
Frequencies,  Bandwidlhs, 
Submit  SS  Cert  (Stage  1} 


Support  Dev  of 
System  Concepts} 


Assist  (a  Define  Sys  ft 
Services  Architectures 


Define  ft  Analyze  SM 
Allocated  Rqrrcts 
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Ail  effective  SM  program  is  instituted  in  the  early  phases  of  the  acquisition  life  cycle  and  anticipates 
challenges  and  obstacles  to  overcome.  As  part  of  the  pre- acquisition  process.  SM  must  be  included  hi  the 
Capabilities  Based  Assessment  (CBA).  taking  hito  account  the  entire  system  lifecycle  for  a  spectrum 
dependent  system.  Considerations  must  be  given  to  the  availability  of  the  particular  electromagnetic  spectrum 
throughout  the  life  span  of  the  system  spectrum  suppoitability,  as  well  as  the  Electromagnetic  Environmental 
Effects  (E3),  which  addresses  Lire  electromagnetic  environment's  impact  on  the  military  operational  capability, 
equipment,  subsystems,  systems  and  platforms. 

According  to  Office  of  Management  and  Budget  (OMB)  Circular  A-ll,  submission  of  funding  estimates  for 
the  development  or  procurement  of  systems  or  equipment  can  only  be  conducted  after  obtaining  spectrum 
support.  In  addition,  spectrum  certification  is  also  a  pre-requisite  to  obligating  finds  for  spectrum-dependent 
equipment  or  systems.  Below  are  the  SM  activities  that  are  highlighted  in  the  respective  phases  of  the 
Ac  quisition  lifecyc  1  e . 

1.  Materiel  Solution  Analysis*  Dining  this  phase  the 
SMC  SM  office  completes  and  submits  inputs  to  the 
program  acquisition  process  in  the  form  of  an  initial 
Stage  1  (Conceptual)  request  for  a  Spectnun 
Suppoitability  Certification  (DD  Form  1494)  for 
approval.  The  DD  Form  1494  provides  data 
pertaining  to  frequency  assignments,  including 
coordination  with  Host  Nations  (HN).  mitigalion/resolution  of  EMI  issues,  as  well  as  integration  of 
Commercial  Items  (Cl)  into  military  platforms  and  installations  to  name  a  few  .  By  submitting  the  Stage  1 
DD  Form  1494.  the  SM  is  indicating  that  initial  planning  has  been  complete,  including  proposed 
frequency  bands  and  other  available  characteristics.  In  addition,  the  SM  office  shall  also  provide  insight  to 
E3  and  Spectrum  Suppoitability  (SS)  functionality  in  the  ICD  to  address  operational  capabilities,  gaps  or 
shortcomings  with  respect  to  spectrum  usage,  access,  or  support  areas.  The  table  to  the  right  exhibits  the 
products  tliat  are  produced  dining  the  Materiel  Solution  Analysis  phase. 

2.  Technology  Development*  In  this  phase  of  the 
acquisition  life  cycle.  The  SM  prepares  and  facilitates  the 
attainment  of  a  Stage  2  SS  Certification  prior  to 
authorization  to  perform  experimental  testing.  A  Stage  2 
SS  Certification  request  indicates  that  the  preliminary 
design  has  been  completed  and  on-air  radiations,  using 
test  equipment  or  preliminary  models  may  be  requir  ed.  It 
must  also  indicate  specific  sites,  geographic  locations  and 
coordinates  of  the  equipment  to  be  used.  The  SM  initiates 
requests  for  HN  authorization  for  the  use  of  spectnun  dependent  equipment  in  the  respective  countries. 
The  table  to  the  right  displays  the  requisite  documentation  that  is  generated  during  the  TD  Phase  as  it 
relates  to  SM. 

The  SM  also  supports  the  solicitation  RPP  development  and  proposal  evaluation  activities.  The  SM 
provides  spectnun  engineering  and  management  technical  inputs  including  requirements,  coup  fiance 
stand  aids,  engineering  approaches  relating  to  SM. 


TD  Phase  -  SMC  Acquisition  Products 


DD  Form  1494 _ 

Updates  to  ASP,  TPS,  QMS _ 

CDD  inputs _ 

TEMP  detailed  planning _ 

RFP,  SOW,  PWS,  CDRLs 

LC  Cost  Estimate  Update  /  CARD  Development _ 

RFP:  SM  objectives  in  the  S00;  SM  related  tasks  in 
SOW,  SM  data  products  in  CDRLs _ 

Detailed  SM  planning,  SEP.  LCMP,  TEMP 


MSA  Phase  —  SMC  Acquisition  Products 


DD  Form  1494 _ 

ASP,,  TPS,  DMS ,TES 

LC  Cost  Estimate  Inputs _ 

RFP  inputs  (SM  requirements;  Safety  assessment 
requirements;  High  level  SM  assessments  of  concepts 

APB,  CCA _ 

SEP,  LCMP  inputs 
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3.  Engineering  &  Manufacturing  Development.  Tlie 
next  phase  of  the  acquisition  lifecycle  capitalizes  on 
the  efforts  produced  in  the  previous  phases.  As  hi  the 
previous  phases,  DoD  Instruction  5000.02  mandates 
that  a  SS  Certification  (Stage  3)  is  provided  prior  to 
authorization  to  operate  for  develop  mental  testing. 

Stage  3  certification  denotes  that  the  major  design  lias 

been  completed  and  radiation  may  be  required,  and  specifies  the  geographic  location  of  the  system. 

4.  Production  &  Deployment,  Operations  &  Support*  In 

the  PD  and  O&S  phases,  the  role  that  SM  plays  is  much 
less  prominent  than  in  earlier  stages  of  the  acquisition 
lifecycle.  This  is  attributable  to  the  fact  that  much  of  the 
SM  effort  is  aimed  at  producing  the  best  possible  solution 
at  an  early  onset  of  the  acquisition  process  in  order  to 
mitigate  potential  electromagnetic  spectrum  conflicts 
between  various  equipment  and  agencies  along  the 
acquisition  timeline.  In  the  PD  phase,  the  final  SS 
Certification  (Stage  4)  is  required  prior  to  authorization  to  conduct  operational  testing  of  a  spectrum 
dependent  system.  Obtaining  Stage  4  SS  Certification  essentially  indicates  development  has  been 
completed  and  final  operating  constraints  required  for  compatibility  need  to  be  identified.  The  SM  ensures 
that  measured  data  for  all  technical  characteristics  such  as  emission  bandwidth,  harmonic  level,  spurious 
levels,  etc  is  provided  upon  submission  for  a  Stage  4  frequency  allocation  application.  The  geographic 
location  of  the  system's  operations  must  also  be  as  specific  as  possible. 

Generally,  the  SM  requirements  are  in  place  by  the  time  the  system  reaches  the  OS  phase  as  this  is  often 
driven  by  financial  and  budgeting  requirements.  However,  minor  changes  to  an  existing  frequency 
allocation  in  lieu  of  a  new7  allocation,  are  permitted  in  post  Stage  4  certification  via  the  ESC  process 
through  the  use  of  a  mechauism  noted  as  LCNote-to-Holders." 

SM  Contributions  to  the  Engineering  Life  Cycle  Framework 

Relationship  to  SE  Organization 

The  SM  plans  and  executes  the  essential  spectrum  management  and  engineering  efforts  in  an  integrated  and 
effective  maimer  within  the  context  and  fiill  support  of  the  overarching  Systems  Engineering  (SE)  function. 
SM  ensures  that  each  SM  SED  contribution  is  timely,  adequate,  consistent,  and  compliant.  The  SM  ensures 
that  their  contributions  are  channeled  through  the  Systems  Engineering  Art  a  lyses  and  Consol  activity. 

SM  contributes  and  integrates  with  the  Systems  Engineering  process  and  activities  as  depicted  inTigure3.  The 
SM  is  an  integral  team  member  in  participating  in  the  development/derivation  of  requirements  and  support  for 
the  requirements  analyses  and  allocations  process  to  derive  the  SM  related  set  of  requirements. 

Strong  participation  hi  the  early  p  re -acquisition  periods  is  a  requirement  for  the  SM  Manager  Engineer.  The 
SM  must  work  closely  with  the  System  Engineers  in  performing  interface  analyses,  as  W'eil  as  the  integration, 
verification  and  validation  planning  and  execution,  hi  performing  the  management  and  control  function,  the 
Systems  Engineer  effectively  integrates  all  engineering  functions  through  the  fiill  system  life  cycle.  The  SM 


P&D  /  G&S  Phase  -  SMC  Acquisition 
Products 


DO  Form  1494 _ 

Stage  4  Note-to-Holders _ 

Updates  to  ASP,  TPS,  DMS _ 

CARD  update/  Inputs _ 

RFP:  SM  objectives  in  the  SOO:  SM  related  tasks  in 
SOW,  SM  data  products  in  CDRLs _ 

Detailed  SM  planning,  SEP,  LCMP,  TEMP  updates 


EMD  Phase  -  SMC  Acquisition  Products 


DP  Form  1494 _ 

Updates  to  ASP,  TPS,  DMS _ 

CARD  update/  inputs _ 

RFP:  SM  objectives  in  the  SOO;  SM  related  tasks  in 
SOW,  SM  data  products  in  CDRLs _ 

Detailed  SM  planning,  SEP,  LCMP,  TEMP  updates 
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Engineer  ensures  that  technical  information,  as  related  to  SM  advances,  is  appropriately  applied  through 
systematic  control,  collaboration  and  sharing  across  the  organization. 

In  order  to  successfully  integrate  SM  into  the  acquisition  lifecycle  phases,  the  SM  is  required  to  actively 
participate  in  the  various  reviews  throughout  the  lifecycle.  This  is  to  ensure  that  the  program's  technical 
baseline  is  sufficient  to  support  the  program's  cost  estimates  and  acceptable  levels  of  risk.  These  reviews  are 
identified  in  each  of  the  following  acquisition  phases  along  with  the  various  Systems  Engineering  technical 
products  and  other  contributions  for  further  clarification. 

Relationship  to  other  SEDs 

SM  SED's  relationship  to  other  SEDs  is  summarized  in  Figure  1.  The  PM  may  also  assign  the  SM  the 
responsibility  to  facilitate  development  of  the  space-to -ground,  ground-to-ground  wireless  links.  If  so,  the  SM 
engineering  efforts  will  likely  be  closely  aligned  to  the  signal  /  antenna  engineers  to  characterize,  define,  and 
design  the  space -to- ground,  ground-to-ground  links  and  associated  system  elements.  The  SM  also  supports 
TSzE  to  ensure  eventual  testing  to  verify  /  validate  SM  related  requirements. 

Tools  Selection  &  Use 

The  SM  considers  effectiveness  and  efficiencies 
gained  by  selecting  and  using  the  best  choice  of 
SM  tools. 


SM  Functions  Requiring  Too 


Spectrum  analyses _ 

Multi-use  frequency  management _ 

Spectrum  planning _ 

Spectrum  supportability  risk  assessments 
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Engineering  Activities  and  Products  over  the  Life  Cycle 

Tlie  following  subsections  summarize  the  SM  Engineer’s  contributions  to  engineering  activities  and  technical 

products  by  DoD  acquisition  phase. 

1 .  Materiel  Solution  Analysis*  During  this  phase  the 
SM  may  provide  inputs  to  and  support  the 
Capabilities  Based  Assessment  process  and  the 
JCIDS  process.  The  Program  Office  SM  may 
support  the  development  of  the  mission  and 
operational  concepts,  support  AoA  studies,  support 
determinations  of  FOMs,  and  characterize 
candidate  frequencies,  bandwidths,  and 
provid e/assess  tedinology  solutions.  The  SM  also 
contributes  to  the  development  of  the  MSA  Phase 
technical  products. 

2.  Technology  Development*  Dining  this  phase  the 
SM  continues  to  provide  inputs  to  and  supports  the 
JCIDS  process  and  activities  to  include  inputs  to 
the  CDD.  Concurrently,  E3  and  SS  requirements 
are  also  requit  ed  to  be  addressed  in  this  phase.  SM 
supports  up  dates  to  include  these  requirements  in 
the  Capability  Development  Document  (CDD). 

The  CDD  typically  addresses  spectrum  requirements  that  cover  safety  issues  related  to  electromagnetic 
energy  radiation/reception,  any  potential  issues  regarding  E3  interference  from  tine  at  emitters,  as  well  as 
interoperability  issues.  It  also  provides  a  forum  of  discussions  on  E3  and  SS  including  interoperability 
matters  involving  Net  Ready-Key  Performance  Parameters  (NR-KPP)  as  it  relates  to  E3,  SS  and  Host 
Nation  Authorizations. 

The  SM  provides  E3  and  SS  requirements  inputs  to  tlie  Information  Support  Plan  (ISP)  and  system 
technical  requirements  documents.  The  ISP  must  address  SS  to  include  Equipment  Spectrum  Certification 
(ESC),  reasonable  assurance  of  the  availability  of  operational  frequencies,  and  consideration  of  E3  control 
in  accordance  with  DoD  Instruction  3222.3.  The  goal  is  to  identify  implementation  issues  such  as  E3  and 
SS  support  needs,  dependencies,  and  interfaces  that  pertain  to  net-readiness,  interoperability  and 
information  supportability,  and  information  sufficiency  concerns. 

The  SM  also  supports  the  engineering  activities  highlighted  within  the  box  titled  Engineering  Activities  for 
System  &  Segment  Development  &  Design  Figure  11  to  commence  system  definition  and  development. 
The  SM  contributes  to  support  development  of  technology  and  transition  roadmaps,  architectural  and  other 
system  trades.  The  SM  assesses  adequacy  of  contractor  spectrum  analyses.  The  SM  assists  to  define  or 
update  die  operational  Electromagnetic  Environment  (EME).  The  table  to  the  right  displays  the  requisite 
documentation  that  is  generated  dining  the  TD  Phase  as  it  relates  to  SM. 


MSA  Phase  —  Technical  Products  Requit  ed 

SMC  Spectrum 
Management  Technical 
Products 

SM  Contributions  to 

Other  Organizations 

High  level  assessment 
proposed  concepts  & 
architectures 

Operational  Concepts 

SM  engineering  inputs  and 
factors  for  concept, 
architecture,  technology 
studies  and  trades 

AoA  Studies 

SM  Requirements 

Initial  Capabilities  Doc  (ICD) 
Development 

TD  Phase  -  Technical  Products  Required 

SMC  Spectrum 
Management  Technical 
Products 

SM  Contributions  to 
Other  Organizations 

Updates  to  SM  requirements 

CDD 

Inputs  to  System  Concepts 

Operational  Concepts 

Factors  for  Studies.Trades 

Operational  Assessments 
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The  SM  also  addresses  E3/SS  testing  requirements  (which  is  to  be  included  in  the  TEMP),  updates  to  the 
operational  Electromagnetic  Environment  (EME),  preparation  and  submission  of  the  Stage  3  DD  Form 
1494  request,  refinement  of  cost  estimates  for  all  E3/SS  tasks  and  related  activities,  and  obtaiimient  of  SS 
approval  for  MS  B. 

3.  Engineering  <&  Maim  fact  nring  Development, 

The  SM  continues  to  provide  inputs  to  and  support 
the  JCIDS  process.  The  SM  supports  the 
development  of  the  Capability  Production 
Document  (CPD).  The  CPD,  like  the  ICD  and  the 
CDD,  must  address  both  E3  and  SS,  including  the 
electromagnetic  environment  in  which  the  system 
is  being  designed  to  operate  in  as  well  as 
interfacing  systems.  It  readdresses  the  NR-KPP  requirements  and  refines  the  detailed  picture  of  the 
spectrum  integration  requirements  covering  safety  issues  related  to  electromagnetic  energy 
radiation/reception,  any  potential  issues  regarding  E3  interference  from  tine  at  emitters,  as  well  as 
interoperability  issues. 

hi  addition,  the  SM  provides  inputs  to  the  ISP.  Similar  to  the  TD  phase,  the  ISP  must  address  SS  to 
include  Equipment  Spectrum  Certification  (ESC),  reasonable  assurance  of  the  availability  of  operational 
frequencies,  and  consideration  of  E3  control.  The  SM  supports  the  engineering  activities  liiglilighted 
within  the  box  titled  Engineering  Activities  for  Detailed  Design  Figure  11  to  commence  detailed  systems 
definition  and  development.  The  SM  contributes  to  development  of  architectural  and  other  system  trades 
and  engineering  analyses.  The  SM  also  contributes  to  the  development  of  the  EMD  Phase  technical 
products.  The  SM  provides  inputs  to  T&E  to  ensure  the  TEMP  is  updated  to  reflect  any  changes  to  E3  and 
SS  metrics,  such  as  the  Measures  of  Effectiveness  (MOEs)  and  Measures  of  Suitability  (MOSs) 
established  in  the  TD  phase.  The  SM  also  considers  any  E3  that  is  a  critical  operational  effectiveness  and 
suitability  parameter  and  provides  an  updated  schedule  for  E3  verification  events  and  responsibilities. 

4*  Production  <&  Deployment  Operations  & 

Support,  The  SM  continues  to  provide  inputs  to 
and  supports  the  JCIDS  process.  The  SM  supports 
OT&E  as  directed  by  the  SE  Lead  to  ensure  SM 
related  requirements  met. 


P&D  /  O&S  Phase  -  Technical  Products 
Required 

SMC  Spectrum 
Management  Technical 
Products 

SM  Contributions  to 

Other  Organizations 

Inputs  tech  baseline  engineering 
changes 

Supportability  assessment 
contribution  report 

Test,  Demo  Reports 

Operational  assessments 
contributions 

EMD  Phase  -  Technical  Products  Required 


SMC  Spectrum 
Management  Technical 
Products 

SM  Contributions  to 
Other  Organizations 

Updates  to  SM  requirements 

CPD 

Updates  to  System  Concepts 

Operational  Concepts 

Technical  Studies/Trades 

Operational  Assessments 

Test,  Demo  Reports 
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Spectrum  Management  Engineers'  Contributions  to  Program  and  Project 
Management 


The  SMC  Program  Office  defines  then-  business  inode!  and  approach  structure  based  primarily  on  their 
program  objectives,  program  and  technical  challenges,  organizational  structure,  as  well  as  program  and 
engineering  planning  (SEP  plus  detailed  engineering  planning). 

The  SM  develops  and  implements  the  essential  detailed  planning  to  acliieve  SM  related  engineering  and 
program  objectives  and  requirements.  The  planning  defines  the  SM  tasks  and  functions  to  be  performed  and 
products  to  be  developed;  timing  of  tasks,  task  outputs,  resources  (skills,  tools,  equipment,  and  completion 
criteria.  The  SM  plans  tasks  to  integrate  SM  activities  across  the  program  office,  between  Contractors  and 
stakeholders.  The  SM  plans  the  tasks  to  establish  and  manage  SM  activities  and  forums;  support  SE&I 
activities  and  Specialty  Engineering  activities;  and  integrate  SM  planning  with  other-  program  and  acquisition 
plans  (i.e.  SEP,  IMP,  ASP,  LCMP). 

Execution  of  the  SM  planning  is  typically  defined  through  the  Systems  Engineering  Operating  Instruction  (01). 
The  SM  assists  to  establish  the  business  model,  develop  program  planning  and  schedules,  and  define  and 
implement  program  processes.  The  SM  ensures  the  SM  components  of  the  program  are  appropriately 
r  epresented  hi  the  progr  am  plans,  program  schedules,  work  breakdown  schedules,  cost  estimates.  The  SM  also 
reports  their  technical  performance  and  progress  to  engineering  and  program  management.  The  SM  shares  in 
the  risk  management  responsibilities  to  identify,  assess,  arid  propose  mitigating  actions  of  SM  related  risks. 
They  also  support  the  Program  Manager's  problem  identification,  resolution,  and  decision  making  processes. 
With  regards  to  risk,  the  procurement  of  spectrum  dependent  systems  requires  the  application  of  risk 
management  tools  to  help  identify  shortfalls  and  potential  future  problems  without  committing  a  large  amount 
of  effort  and  resources.  The  Spectrum  Support  ability  Risk  Assessment  (SSRA)  is  a  tool  that  contributes  toward 
successful  Program/Project  management  with  respect  to  the  SM  discipline.  The  SSRA  is  used  to  provide  risk 
assessments  that  increase  in  detail  as  the  spectrum  dependent  system  design  matures.  It  assists  in  identifying 
regulatory,  operational  and  technical  SS  risks,  and  affords  the  progranfproject  manager  opportunities  to 
mitigate  and  deconflict  potentially  disastrous  SS  issues.  This  tool  is  utilized  throughout  the  acquisition, 
engineering  and  management  lifecycle  and  is  integr  ated  into  the  ISP. 

The  table  in  this  section  identifies  the  program  management 
products  that  the  SM  office  contributes  toward  developing. 


SMC  Program  Management  Product 


PMD,  IMP,  IMS,  WBS 


Technical  progression  and  issues 


LC  Cost  Estimate 


Processes  (Operating  Instructions) 


Risk  Management  inputs  (SSRA) 
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Concept  Development 


Appendix  I  -  Concept  Development 

Generally,  concept  development  begins  with  the  development  of  the  joint  operating  concepts,  joint  functional 
concepts,  and  joint  integrating  concepts  that  are  developed  by  the  operating  or  using  commands. 
Representatives  from  impacted  DoD  communities  examine  multiple  concepts  to  optimize  the  way  the 
Department  of  Defense  provides  the  hitended  capabilities.  The  analyses  results  of  the  concepts  then  contribute 
to  the  initial  development  of  the  iCD.  A  system  concept  development  effort  is  then  initiated  once  a  capability 
shortfall  or  an  emerging  or  evolving  change  to  a  military  threat  has  been  identified  and  it  has  been  determined 
that  a  new  or  revised  system  is  required. 

This  SED  highlights  XR's  tasks  and  products  and  further  delineates  the  Program  Office  tasks  and  products  in 
support  of  the  development  of  the  operational  and  system  concepts.  Instructions,  guidance,  and  senior  experts 
are  available  at  SMC/XR  to  assist  the  Program  Office  to  execute  the  essential  concept  development  activities 
for  the  Program  Office. 

Typically,  the  Program  Office  supports  XR  in  the  efforts  to  initially  develop  system  concept  alternatives  then 
determine  and  document  the  preferred  system  concept.  As  a  system  concept  matures,  and  is  determined  to  be 
the  preferred  concept,  the  XR  developmental  planning  efforts  may  be  transitioned  to  the  Program  Office  To  be 
further  advanced  iu  technical  fidelity  aud  evolve  with  the  program  ensuring  that  the  required  capability  meets 
the  iniiitaiy  need.  A  proper  concept  development  effort  facilitates  subsequent  program  phases  that  define, 
produce  and  deliver  materiel  solutions  within  an  identified  trade -space  in  support  of  capability  needs  analyses. 
Developing  a  concept  for  a  new  or  improved  system  requires  the  application  and  rigor  of  the  systems 
engineering  process  that  responds  to  a  new  or  evolving  operational  needs  or  deficiencies.  While  a  top  down 
flow  of  activities  appears  in  a  typical  concept  development  cycle,  in  reality  the  concept  development  is  more 
often  than  not  an  iterative  process  with  multiple  iterations  and  influences  from  many  participants.  These 
include  Operators.  Maintained,  Technologists.  Engineers,  and  the  Acquisition  Community  participation. 
While  system  concept  development  is  often  performed  or  led  by  a  systems  engineer,  it  is  usually  accomplished 
by  a  team  that  can  be  characterized  as  “A  Community  of  Interest".  For  the  purpose  of  this  document,  we  will 
call  this  individual  or  team  the  Concept  Developer. 

The  Concept  Developer  plans  and  performs  the  essential  engineering  conceptual  development  and 
management  efforts  to  ensure  that  the  resulting  program  is  timely,  adequate,  consistent,  and  compliant  with  the 
military  need. 

Applicable  governance,  standards,  and  guidance 

Policy,  directives,  and  instructions  that  mandate  concept  development  related  program  requirements  are 
included  in  a  wide  range  of  mandates.  Table  14  below  identifies  the  significant  governance,  standards,  and 
guidance  which  generally  require  SMC  compliance  for  concept  development. 

DOD  Instruction  5000.02  requires  the  joint  operating  concepts,  joint  functional  concepts,  and  the  concept  of 
operations  be  initiated  prior  to  the  Materiel  Solution  Analysis  phase.  The  preferred  system  concept  is  then 
determined  during  the  Technology  Demonstration.  In  general,  a  Milestone  B  is  planned  when  a  system  concept 
has  been  selected. 
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AFSPC  Instruction  10-102  provides  clarification  for  a  space  system's  system-level  CONOPS  as  the  enabling 
concept  defined  as  a  high-level  written  description  of  a  space  system  that  identifies  the  system's  purpose, 
operational  assumptions,  the  desired  effects,  how  the  system  will  be  used,  and  who  is  envisioned  to  operate  and 
use  it. 

Table  14  Governance,  standards,  and  guidance  that  shape  tlie  Concept  Development  discipline 


Document  No 

Governance  Title 

Issue 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

CJCSI 3010  02B 

Joint  Operations  Concepts  Development  Process  (JOpsC-DP) 

27  Jan  06 

CJCSI  3170.01G 

Joint  Capabilities  Integration  and  Development  System 

01  Mar  09 

AF1 10-601 

Operational  Capability  Requirements  Development 

12  JuMO 

AF1 10-604 

Capabilities -Based  Planning. 

10  May  06 

AF1 10-2801 

Air  Force  Concept  Of  Operations  Development 

24  Oct  05 

AFI 63-101 

Acquisition  and  Sustainment  Life  Cycle  Management 

22  Mar  11 

AFI 63-1201 

Life  Cycle  Systems  Engineering 

23  Jul  07 

AFI  99-103 

Capabilities  Based  Test  And  Evaluation 

6  Aug  04 

AFSPC1 10-102 

Concept  Development 

15  Nov  08 

AFSPCI 61-101 

Space  Science  And  Technology  (S&T)  Management 

18  Oct  07 

Document  No 

Standards  Title 

Issue 

I  SMC-S-001  | 

Systems  Engineering  Requirements  &  Products 

I  12  July  10  t 

Document  No 

Guidance  Title 

Issue 

Joint  Operations  Concepts  Development  Process  (JOPSC-DP)  Pocket 
Guide 

9  Jan  08 

DoDAF  2.0 

Department  of  Defense  Architecture  Framework  20  Volumes,  1.2,3 

28  May  09 

DAU  DAG 

Defense  Acquisition  Guidebook 

05  May  10 

DISR 

http  s :  //www .  di  sronline .  di  s  a .  mil 

SMC-G-001 

Systems  Enqineenng  Implementation  Guide 

17  Apr  09 

FY08  Space  Technical  Planning  Integrated  Product  Team  (TPIPT) 

Concept  Data  Collection  Guide  (Interim) 

SMC  /  XR  Concept  Development  Guide  (Interim) 

Concept  Development  Contributions  to  the  Acquisition  Life  Cycle 

The  Do D  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  Concept  Development  contributions  over  tills  life 
cycle  are  best  represented  within  the  phases  of  the  Defense  Acquisition  Management  System.  Figure  12 
provides  the  acquisition  life  cycle  framework  within  which  the  Concept  Developer  performs  as  w  ell  as  the 
products  that  the  Concept  Developer  must  develop  or  contribute  to  their  development. 


The  Concept  Developer  defines  and  implements  concept  development  strategies  and  objectives  consistent 
within  the  tenets  of  applicable  policies,  SMC  acquisition  objectives  and  requirements,  and  program  objectives, 
requirements,  and  constraints.  The  Concept  Developer  assists  the  operating  organizations  to  develop,  attain 
approval  for,  and  implement  operational  concepts  into  a  CONOP  and  capability  documents  as  they  fit  into  the 
acquisition  cycle,  e.g.  Initial  Capability  Document  (ICD),  Capability  Development  Document  (CDD),  and 
Capability  Production  Document  (CPD).  This  planning  will  be  firmly  based  on  program  and  technical 
objectives,  strategies.  DOD  mandates,  and  instructions. 

The  need  to  develop  space  concepts  may  originate  from  any  AFSPC  Directorate,  NAF,  and  Wing,  the  Air  Staff 
or  a  unified  commander.  Command  Leads  are  (or  SMC  Leadership  is)  responsible  for  developing  concepts  that 
fall  writhin  their  relevant  core  capability  area.  The  planning  defines  concept  development  activities  and 
products  to  achieve  the  overall  program  objectives  and  requirements;  specifies  tasks  and  functions  to  be 
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perfonned.  liming  of  Tasks,  resources  required,  products  to  be  developed  forms  the  basis  for  the  Space 
Technic  a!  Planning  Integrated  Product  Teams  (TPIPTs)  Concepts.  For  early  concept  development,  the  concept 
development  planning  is  executed  per  the  SMC  /  XR  C  oncept  Development  Guide  that  documents  the  process 
to  perform,  control,  and  integrate  concept  development  and  management  activities.  When  the  preferred  system 
concept  is  determined  and  approved,  the  concept  development  efforts  are  transferred  horn  XR  to  the  Program 
Office  where  the  emphasis  is  refinement  of  the  system  concept (s). 

The  Program  Office  concept  planning  is  based  on  the  appropriate  program-approved  life  cycle.  SMC  Program 
Offices  define  and  implement  the  system  concept  development  strategies  and  objectives  consistent  within  the 
tenets  of  appropriate  policies,  SMC  acquisition  objectives,  and  program  objectives.  At  SMC,  the  Program 
Office  Concept  Developer  supports  the  major  acquisition  activities  through  the  frill  system  life  cycle  to  ensure 
concept  development  and  program  requirements  are  fully  extended  through  SMC  specific  programs  and  their 
developments. 

1*  Pre-Materiel  Solution  Analysis*  Dining  this  phase, 

SMC/XR  is  typically  the  key  SMC  player  in  supporting 
the  Capability  Based  Assessment  (CBA)  development 
though  the  Program  Office  Concept  Developer  may  also 
support  the  CBA.  SMC/XR  and/or  the  Program  Office 
Concept  Developer  will  use  the  results  of  the  CBA  and 
any  accompanying  enabling  concepts  to  propose  potential 
solutions  to  identified  capability  needs  and  apply  them  to  SMC  Development  Plans.  Development  plans 
which  are  vetted  through  concept  assessment  teams  are  provided  as  inputs  to  the  I  CD  and  AoA  Study 
Plan.  Concept  development  is  integrated  into  the  JROC's  deliberations  on  identifying,  developing, 
validating,  and  prioritizing  requirements. 

2.  Materiel  Solution  Analysis*  During  tills  phase  the 
Concept  Developer  provides  inputs  to  and  supports 
program  acquisition  activities  to  include  the  development 
of  the  acquisition  strategy,  technology  demonstration,  test 
strategies,  inputs  to  the  cost  estimates.  soiicitation/RFP 
development  for  Contractor  studies,  and  proposal 
evaluation  activities.  The  Concept  Developer  also  contributes  to  the  development  of  the  MSA  Phase 
acquisition  products.  In  addition,  die  Concept  Developer  verifies  concept  component  functionality  against 
desired  capabilities.  The  XR  leads  or  supports  the  system  alternative  concept  analyses,  concept  models, 
and  acquisition  planning  needed  to  fully  develop  a  concept  to  where  it  can  be  transitioned  to  a  SPO.  The 
Concept  Developer  also  contributes  to  the  development  of  the  acquisition  MSA  Phase  products. 


MSA  Phase  —  SMC  Acquisition  Products 


inputs  to  AoA,  ICD _ 

:ds,  dms _ 

LC  Cost  Estimate _ 

RFP  inputs:  System  Concepts,  Ref  Architectures 

SEP 


Pre-MSA  Phase  -  SMC  Acquisition 
Products 


Inputs  to  joint  operating,  joint  functional,  &  joint 
integrating  concepts _ 

Inputs  to  CBA _ 

Inputs  to  Draft  ICD _ 

Inputs  to  AoA  Study  Rian 
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3.  Technology  Development.  During  this  phase,  the 
Concept  Developer  works  closely  with  the  Systems 
Engineers  and  Architecture  Engineers,  to  analyze,  trade, 
refine,  arid  validate  system  concepts  against  the  already 
defined  user  needs.  The  Concept  Developer  provides 
inputs  to  and  supports  program  acquisition  activities  to 
include  the  acquisition  strategy,  technology  development 
strategy,  cost  model,  and  solicitation/ RFP  development 
and  proposal  evaluation  activities.  The  Concept 
Developer  along  with  the  Architecture  Engineer 
establishes  the  functional  and  the  physical  architectme 
thereby  assisting  Systems  Engineering  to  define  the 
allocated  baseline  (preliminary  design)  with  additional  emphasis  on  maturing  tecluiologies  with  a  TRL6 
before  milestone  B  approval. 

4.  Engineering  &  Manufacturing  Development.  The 
Concept  Developer  provides  inputs  to  and  supports 
program  acquisition  activities  to  include  updates  to  the 
acquisition  strategy  and  updates  to  the  cost  model  to 
reflect  any  change  of  technical  solutions  determined  and 
updates  to  the  CARD,  inputs  are  also  provided  to  identify 
system  design  constraints  determined  through  concept 
analyses  and  refine  system  design  requirements  as  a  result 
of  the  iterative  engineering  analyses  and  developmental 
tests.  The  Concept  Developer  supports  the 
solicit  at  loiiRFP  preparation  and  operational  concept 
development  documented  in  the  CPD  to  meet  program  objectives  The  Concept  Developer  ensures  that  the 
matured  concept  meet  user  capability  needs  and  is  consistent  and  in  alignment  with  the  contractual 
requirements.  The  Concept  Developer  contributes  to  the  development  and  updates  to  the  acquisition 
products  identified  hi  the  table.  One  of  the  main  objectives  is  to  attain  TRL7  or  above  for  milestone  C 
approval. 

5.  Production  &  Deployment,  Operations  &  Support. 

The  Concept  Developer  provides  inputs  to  and  supports 
program  acquisition  activities  to  include  updates  to  the 
acquisition  strategy  and  to  the  cost  model  to  reflect  the 
actual  technical  solutions.  The  Concept  Developer  also 
ensures  proper  implementation  of  inputs  previously 
provided  to  reduce  integration  and  manufacturing  risk  and 
critical  support  ability  aspects  focusing  on  minimizing  the 
logistics  footprint.  The  concept  development  team 
supports  post  incrementation  review  vliich  compares  actual  system  performance  to  program  expectations 
and  mission  realities  based  upon  the  operational  enviroiunent  and  CONORS. 


P&D  /  O&S  -  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS _ 

CARD  update _ 

RFP:  Concept  development  related  tasks  in  PWS, 
Concept  data  requirements  products  in  CDRLs;  Data 
Item  Description  -  tailored _ 

Final  ISP _ 

Concept  development/validation  planning,  SEP, 
LCMP,  TEMP  updates 


EMD  Phase  -  SMC  Acquisition  Products 


Updates  to  ASF,  TPS.  DMS _ 

Inputs  for  CARD  update _ 

REP:  Concept  &  Architecture  objectives  in 
the  SOO;  Concept  development  related  tasks 
in  PWS,  Concept  data  requirements  products 
in  C  DRLs;  Data  Item  Description  -  tailored 

ISP:  System  operations  concept _ 

CPD  inputs _ 

APB:  Concept  descriptions _ 

Concept  development  planning;  inputs  to  SEP  LCMP, 
TEMP,  ISP 


TD  Phase  —  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS _ 

System  Cost  Model,  LC  Cost  Estimate  Update  /  CARD 
Development _ 

RFP:  System  Concepts,  Ref  Architectures;  Concept  & 
Architecture  objectives  in  the  SOO;  Concept 
development  related  tasks  in  PWS,  Concept  data 
requirements  products  in  CDRLs;  Data  Item 
Description  -  tailored _ 

ISP:  operational  concept _ 

Inputs  to  CDD:  Concepts  of  operation,  description  of 
the  needed  capability,  operational  risk _ 

APB:  Concept  descriptions _ 

Concept  planning:  Inputs  to  SEP,  LCMP,  TEMP,  ISP 
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Support  C  BA: 
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Concept  Development  Contributions  to  the  Engineering  Life  Cycle 
Relationship  to  the  SE  Organization 

The  Concept  Developer  plans  and  executes  the  essential  concept  development  and  management  efforts  in  an 
inte grated  and  effective  manner  witlim  the  context  of  system  engineering.  Other  participants  that  support  the 
concept  development  function  may  include  implementors,  integrators,  other  specialty  engineers,  and 
representatives  of  die  eventual  using  organizations.  The  Concept  Developer  ensures  that  each  of  the  SED 
contributions  is  timely,  adequate,  consistent,  and  compliant.  The  Concept  Developer  ensures  that  then 
contributions  are  channeled  duough  the  Systems  Engineering  Analyses  and  Control  activity. 

Systems  Engineers  manage  the  engineering  process  and  activities  depicted  hi  Figure  3  while  die  Concept 
Developer  contributes  to  this  process  by  performing,  managing,  and  supporting  the  concept  development  effort 
through  the  use  of  modeling  and  simulation,  analyses;  cone  ept/arclntectura  1/de  sign  hades;  and  technology 
studies.  The  Concept  Developer  contributes  to  the  Systems  Engineering  process  and  supports  teclmical  and 
program  management  activities  by  supporting  decision  making. 

Relationship  to  other  SEDs 

The  Concept  Developer  SED's  relationship  to  other  SEDs  is  summarized  in  Figure  1.  The  Program  Office 
Concept  Developer  is  likely  most  closely  aligned  with  the  Arcliitecture  Engineer  or  Team  and  the  System 
Engineer  to  proride  and  trade  on  plausible  system  technical  solutions.  Specifically,  the  Concept  Developer 
supports  concept  and  architecture  development  and  analyses;  modeling  and  simulation  efforts;  technology 
studies:  and  design  trades  as  well  as  supporting  teclmical  and  program  management  activities  and  decision 
making.  The  Concept  Developer  supports  the  Architecture  Engineer  to  assist  in  the  requirements  development 
activities  and  requirements  analyses  by  creating  dynamic  system  models,  a bs fractions  of  a  particular  domain 
concept,  or  models  to  define  system  functions  then  allocate  and  parameterize  requirements  to  perform  the 
function. 

The  Concept  Developer  along  with  the  Arcliitecture  Engineer  supports  the  system  trades  taking  into  account  all 
applicable  factors  to  ensure  balanced  and  integrated  architecture  solutions.  The  Concept  Developer  works 
closely  with  the  Logistics  Specialists  to  incorporate  their  deployment  and  sustainment  concepts  to  reduce 
integration,  deployment,  and  manufacturing  risk  and  critical  support  ability  aspects  focusing  on  minimizing  the 
logistics  footprint. 

Tools  Selection  and  Use 

The  Concept  Development  team  considers 
effectiveness  and  efficiencies  gained  by  selecting 
and  using  the  best  choice  of  Modeling  and 
Simulations  tools  to  perform  modeling  and 
simulation  analyses,  information  sharing, 
automated  data  exchanges  with  other  tools,  and  other  considerations. 

Engineering  Activities  and  Products  over  the  Life  Cycle 

SMC/XR  leverages  the  results  of  the  Capability  Based  Assessment  (CBA)  and  any  accompanying  enabling 
concept  and  supporting  analyses  to  propose  potential  solutions  to  identified  capability  needs  and  apply  them  to 


Concept  Development  Functions  Requiring  Tools 


Architectural  Development _ 

Modeling  ft  Simulations _ 

Technology  Trade  Studies  and  Data  Analysis 

Operational  Concept  Analysis 
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the  product  center  Development  Plans.  SMC/  XR  also  manages  the  Program  Executive  Officer  (PEG)  / 
Technology  Executive  Officer  (TEO)  and  Space  Teclmology  Integration  Council  (STIC)  process  to  produce 
developmental  plans  for  high-priority,  near-,  mid-  and  far-term  concepts  for  inclusion  hi  the  Science  and 
Technology  Guidance  Document.  As  concepts  approach  the  mid  to  far  term  it  starts  becoming  inappropriate  to 
try  to  cost  the  concept  as  systems  in  acquisition  can  usually  be  estimated  to  a  factor  of  2  to  3.  As  more  new 
technologies  are  needed  cost  estimates  start  becoming  appropriate  to  only  an  order  of  magnitude.  For  far  term 
concepts  needing  a  lot  of  new  teclmologies  the  XR  Concept  Developer  appropriately  specifies  the  cost  a 
system  should  meet  rather  than  specifically  what  it  will  cost.  In  the  far  term  cost  targets  become  a  goal  and  the 
system  design  and  teclmology  needs  specified  to  meet  these  goals. 

The  transition  of  concept  development  activities  from  XR  to  the  Program  Office  vary  from  program  to 
program.  In  most  cases,  the  Program  Office  Concept  Developer  ini  tiates  a  broader  system  and  program  concept 
development  perspective  while  further  enabling  and  maturing  concepts.  Similar  to  the  XR  Concept  Developer, 
the  Program  Office  Concept  Developer  continues  to  participate  in  technical  trades  to  transform  warfighter 
needs  into  teclmical  solutions,  identify  needed  teclmologies.  generate  developmental  roadmaps,  and  mature 
technologies,  and  deliver  materiel  and  operations  solutions  to  operators 

The  Concept  Developer  also  ensures  that  the  system  concept  evolves  and  is  appropriately  captured  in  the 
system  design  considering  program  objectives,  requirements,  and  constraints  and  balancing  conceptual 
solutions  with  a  wide  range  of  engineering  factors  to  include  those  of  safety,  reliability,  human  systems 
integration,  security,  supportability,  environmental,  and  of  course  cost. 

For  software  developments  by  applying  use  case  techniques,  the  Concept  Developer  can  assist  the  engineering 
team  capture  system  behavioral  requirements  by  detailing  scenario -driven  threads  through  functional 
requirements.  By  creating  other  functional  and  dynamic  system  models,  abstractions  of  a  particular’  domain 
concept,  and/or  models,  the  Concept  Developer  assists  the  Systems  Engineers  in  defirring  system  functions, 
parameterizing  requirements  and  providing  functional  and  physical  decomposition  of  design  hades  and 
interface  definitions. 

The  Concept  Developer  plans  and  executes  the  essential  concept  development  and  management  efforts  to 
ensure  that  each  concept  contribution  is  timely,  adequate,  consistent,  and  compliant.  The  Concept  Developer 
ensures  contributions  are  channeled  through  the  Systems  Engineering  activities  so  that  system  evolution 
decisions  are  properly  vetted  and  documented. 

The  following  subsections  summarize  the  Concept  Developer  contributions  to  engineering  activities  and 
technical  products  by  DoD  acquisition  phase. 
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1.  Pre-Materiel  Solution  Analysis.  SMC/XR 
is  a  key  player  in  the  Capability  Based 
Assessment  (CBA)  development  though  the 
Program  Office  Concept  Developer  may 
also  support  the  CBA.  During  this  phase, 

SMC/XR  is  typically  the  key  SMC  player  hi 
supporting  the  Capability  Based  Assessment 
(CBA)  development  SMC/XR  and/or  the 
Program  Office  Concept  Developer  will  use 
the  results  of  the  CBA  and  any  accompanying  enabling  concepts  to  propose  potential  solutions  to 
identified  capability  needs  and  apply  them  to  SMC  Development  Plans.  Development  plans  which  are 
vetted  through  concept  assessment  teams  are  provided  as  inputs  to  the  ICD  and  AoA  Study  Plan.  Concept 
development  is  integrated  into  the  JROC’s  deliberations  oil  identifying,  developing,  validating,  and 
prioritizing  requirements.  The  Program  Office  Concept  Developer  leads  or  supports  XR  in  the  efforts  to 
develop  system  concept  alternatives  then  determine  and  document  the  preferred  system  concept 


Pit -MSA  Phase  —  Technical  Products  Required 


SMC  Concept  Development 
Technical  Products 

Concept  Bevel 
Contributions  to  Other 
Organization?’  Products 

System  Architecture  Reqts  (draft 

Inputs  to  CBA 

High  level  performance  and 
sustainment  analyses 

Inputs  to  AoA  Studies , 

Technology  Roadmap 

Architecture  inputs  and  factors  for 
concept,  architecture,  technology 
studies,  and  trades 

Inputs  to  Operational  Concepts 

2.  Materiel  Solution  Analysis*  During  tliis 
phase  the  Concept  Developer  may  provide 
inputs  to  and  support  the  Capabilities  Based 
Assessment  process  and  the  JCIDS  process. 

The  Concept  Developer  contributes  to  the 
development  of  the  mission  and  operational 
concept  models  and  provides  assistance  to 
architecture  artifacts.  The  Concept 

Develop  er  also  contributes  to  the 

development  of  the  MSA  Phase  tecluiical  products  ensuring  to  minimize  complexity  both  witlrm  the 
system  and  with  regards  to  the  system  external  interfaces. 


MSA  Phase  —  Technical  Products  Required 


SMC  Concept  Development 
Technical  Products 

Concept  Devel 
Contributions  to  Other 
Organization^  Products 

High  level  performance  and 
sustainment  analyses 

Inputs  to  CBA;  ICD 

Architecture  inputs  and  factors  for 
concept,  architecture,  technology 
studies,  and  trades;  CVs,  OVs 

Inputs  to  AoA  Studies , 

Technology  Roadmap 

Enabling  Concepts 

Inputs  to  Operational  Concepts 

3.  Technology  Development  During  this 
phase  the  Concept  Developer  main  focus  is 
to  demonstrate  and  validate  system  concept 
processes  hi  order  to  ensure  delivery  of 
integrated,  matured  technologies.  The 

Concept  developer  continues  to  provide 
inputs  to  and  supports  the  JCIDS  process 
and  activities.  The  Concept  Developer  also 
supports  the  concept  development  activities 
liighlighted  within  the  box  titled 

Engineering  Activities  for  System  &  Segment 
Development  A  Design  Figure  12  to  commence  system  definition  and  development.  The  Concept 
Developer  contributes  to  development  of  technology  roadmaps,  avoiding  use  of  high  risk,  immature 
technologies,  and  system  hades  and  analyses.  The  Concept  Developer  contributes  to  the  development  of 
TD  Phase  technical  products  with  emphasis  on  enabling  and  critical  teclmologies. 


TD  Phase  -  Technical  Products  Required 


SMC  Concept  Development 
Technical  Products 

Concept  Devel 
Contributions  to  Other 
Organizations T  Products 

Inputs  for  performance  and 
sustainment  analyses 

Inputs  to  CBA;  CDD 

Architecture  inputs  and  factors  for 
concept,  architecture,  technology 
studies,  and  trades;  CVs,  OVs, 

SVs,  SvcVs,  StdVs,  AVs, 

Inputs  to  AoA  Studies , 

Technology  Roadmap 

Enabling/System  Concepts 

Inputs  to  Operational  Concepts  & 
Assessments 

Factors  for  Studies/  T rades 
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4.  Engineering  &  Manufacturing 
Development,  At  this  stage,  the  Concept 
Developer  contributes  to  reducing 
integration  and  manufacturing  risk,  and 
design-in  critical  suppoitability  aspects.  The 
Concept  Developer  continues  to  provide 
inputs  to  and  support  the  JCXDS  process. 

The  Concept  Developer  supports  the  concept 
development  activities  highlighted  within 
the  box  titled  Engineering  Activities  for 
Detailed  Design  Figure  12  to  commence 
detailed  systems  definition  and 
development.  The  Concept  Developer 
contributes  to  development  of  technology  roadmaps  and  system  trades  and  analyses.  The  Concept 
Developer  also  contributes  to  the  development  of  the  EMD  Phase  technical  products  and  completion  of  the 
teclmical  base  hue  to  include  baseline  concept  development  products  and  data.  The  Concept  Developer 
supports  prototyping,  prototype  testing,  modeling  and  simulation,  DT&E  as  directed  by  the  Systems 
Engineering  Lead  to  ensure  interoper  ability,  system  integration,  supportability.  safety,  utility  and  other 
requirements  assigned  to  the  concept  development  to  meet  system  operational  capability. 

5.  Production  &  Deployment,  Operations  <& 

Support.  The  Concept  Developer  continues 
to  provide  inputs  to  and  supports  the  JCIDS 
process.  The  Concept  Dev  eloper  ensures  the 
actual  system  performance  to  program 
expectations  and  mission  realities  based 
upon  the  operational  environment  and 
CONOPS  are  met. 


P&D  /  O&S  Phase  -  Teclmical  Products  Required 


SMC  Concept  Development 
Teclmical  Products 

Concept  Devel 
Contributions  to  Other 
Organizations*  Products 

Operational  Assessments 

Supportability  Analyses  Rpt 

Operational  Concepts  and 
Models 

Inputs  tech  baseline  engineering 
changes 

System  Concepts 

Inputs  to  Transition  &  Fielding 
Docs 

EMD  Phase  —  Technical  Products  Required 


SMC  Concept  Development 
Teclmical  Products 

Concept  Devei 
Contributions  to  Other 
Organiza  lions !  Pr  od nets 

Inputs  for  performance  and 
sustainment  analyses 

Inputs  to  CBA,  CRD 

Architecture  inputs  and  factors  for 
concept,  architecture,  technology 
studies,  and  trades;  ISP;  CVs, 
OVs.SVs,  SvcVs;  StdVs,  AVs; 

Inputs  to  AoA  Studies  , 

Technology  Roadmap 

Evolving  System  Conoept(s) 

Inputs  to  Operational  Concepts  & 
Assessments 

Factors  for  Studies/  Trades 

Inputs  to  system,  production, 
fielding,  sustain  design  docs 
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Concept  Development  Contributions  to  Program  and  Project 
Management 

Each  Concept  Developer  defines  their  conceptual  model  approach  and  planning  based  primarily  on  the 
required  operational  capabilities  and  objectives,  conceptual  designs  and  technical  challenges,  such  as 
technology  maturation  and  any  demonstrated  deficiencies.  The  Concept  Developer  supports  program 
management  activities  and  program  level  management  decisions,  by  contributing  to  the  risk  management 
process,  providing  cost  models  for  cost  estimating  and  budget  planning,  assisting  and  developing  technology 
roadmaps  to  define  future  states  of  a  system,  e.g.,  To-Be  and  Objective  states,  operational-need  solutions, 
mission-need  solutions,  and  to  evolve  systems  to  achieved  pre-planned  incremental  capabilities. 

The  Concept  Developer  develops  and  implements  the  concept  development  program  planning  to  achieve  the 
required  objectives  and  requirements.  The  planning  defines  the  concept  development  tasks  and  functions  to  be 
performed;  products  to  be  developed;  and  timing  of  tasks,  task  outputs,  resources  (skills,  tools,  equipment,  and 
completion  criteria).  The  Concept  Developer  plans  tasks  to  integrate  concept  development  activities  witlrni  the 
Program  Office,  between  contractors,  and  community  stakeholders.  The  Concept  Developer  plans  the  tasks  to 
establish  and  manage  operations  and  system  concepts,  support  SE&I  activities,  e.g.,  system  technical  solutions 
trades  and  analyses  risk  management,  integration,  and  system  modifications;  coordinate  the  concept 
development  planning  with  Systems  Engineering,  operating  commands,  supporting  commands,  and  test 
agencies;  and  integrate  the  planning  with  other  fiuictioiial  and  acquisition  plans  (i.e.  SEP,  ASP,  LCMP). 
Execution  of  the  concept  development  planning  is  typically  defined  thr  ough  an  Operating  Instruction  (OI).  The 
Concept  Developer  provides  full  support  to  define  the  program  and  technical  objectives  where  concept  and 
architectural  challenges  and  risks  are  known  or  anticipated.  The  concept  and  arcliitecture  team  assist  in 
establishing  the  business  model,  developing  program  planning  and  schedules,  and  defining  and  implementing 
program  processes.  The  Concept  Developer  ensures  the  concept  development  and  management  components  of 
the  program  are  appropriately  represented  in  the  program  plans,  program  schedules,  work  breakdown 
schedules,  and  cost  estimates.  The  Concept  Developer  reports  their  teclinical  performance  and  progress.  The 
Concept  Developer  shares  in  the  risk  management  responsibilities  to  identify,  assess,  and  propose  mitigating 
actions  of  their  related  risks.  Concept  Developer  also  supports  the  program  manager’s  problem  identification, 
resolution,  and  decision-making  processes. 
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Appendix  J  -  Architecture  Engineering 

SMC  Program  Office  Systems  Engineering  organization  designates  a  POC  (referred  to  in  tills  SED  as  an 
Architecture  Engineer)  who  implements  the  DoD  and  Air  Force  interoperability.  IT,  and  acquisition  mandates 
and  engineering  best  practices  requiring  architectural  contributions.  Policies  and  mandates  that  affect  SMC 
architecture  commitments  and  architecture  decisions  are  many,  hi  the  interoperability  and  information 
technologies  categories,  the  mandates  are  partly  driven  by  evolving  DoD  Net-Centric  warfare  (NCW)  doctrine 
to  radically  improve  information  sharing  by  employing  robust  modern  information  technologies. 

In  addition,  investments  in  front  end  systems  modeling  and  analyses  allows  the  Program  Office  to  commence 
acquisitions  with  more  complete  system  level  requirements  sets  and  sufficient  or  high  fidelity  requirements, 
functional,  and  physical  allocations  to  support  our  acquisition  strategic  planning,  technologies  assessments,  and 
prepare  the  te  clinic  a  l  components  of  a  REP.  Through  applying  use  case  techniques,  the  Architecture  Engineer 
assists  the  engineering  team  capture  system  behavioral  requirements  by  detailing  scenario -driven  threads 
through  functional  requirements.  By  creating  dynamic  system  models,  abstractions  of  a  particular  domain 
concept,  and' or  models,  the  .Architecture  Engineer  assists  the  Systems  Engineers  to  define  system  functions, 
parameterize  requirements  to  perform  the  finictions.  and  provides  functional  and  physical  decomposition  of 
design  trades  and  interface  definition  and  decisions.  Systems  modeling  and  analyses  is  a  time -proven  approach 
that  reduces  requirements  creep,  reduces  costly  engineering  changes  and  keeps  control  of  the  development 
schedule  by  identifying  and  mitigating  technical  risks  early.  In  addition,  architecture  products  are  essential  to 
describe  operational  and  system  concepts,  operational  environments  such  as  production,  integration  and 
sustainment,  and  mission  scenarios. 

The  Architecture  Engineer  plans  and  executes  the  essential  architecture  development  and  management  efforts 
in  an  integrated  and  effective  manner  to  ensure  that  each  Architecture  SED  contribution  is  timely,  adequate, 
consistent,  and  compliant.  The  Architecture  Engineer  ensures  that  their  contributions  are  channeled  through  the 
Systems  Engineering  Analyses  and  Control  activity.  The  architecture  team  also  supports  engineering  efforts, 
acquisition  activities,  and  management  activities  and  decision  making. 

Applicable  governance,  standards,  and  guidance 

Policy,  directives,  and  instructions  that  mandate  architecture  engineering  related  program  requirements  are 
included  in  a  wide  range  of  mandates.  Table  15  below7  identifies  the  significant  governance,  standards,  and 
guidance  which  generally  require  SMC  compliance  for  architecture  engineering. 

Table  15  Governance,  standards,  and  guidance  that  shape  the  Architecture  Engineering  discipline 


Document  No 

Governance  Title 

Issue 

Net-centric  Enterprise  Solutions  for  Interoperability  (NESI)  Policy 

08  Jun  05 

DoDD  8000.01 

Management  of  the  DoD  Information  Enterprise 

10  Feb  09 

DoDD  4630.05 

Interoperability  and  Supportability  of  Information  Technology  (IT)  and 
National  Secunty  Systems  (NSS) 

23  Apr  07 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

DoDl  4630. 8 

Procedures  for  Interoperability  and  Supportability  of  Information 
Technology  (IT)  and  National  Security  Systems  (NSS) 

30  Jun  04 

CJCSI 31 70.01  G 

Joint  Capabilities  Integration  and  Development  System 

01  Mar  09 

CJCSI  6212.01  E 

Interoperability  And  Supportability  Of  Information  Technology 

And  National  Security  Systems 

15  Dec  08 
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Air  Force  Policy  on  Enterprise  Architecting 

06  Aug  02 

AF 133-124 

Enterprise  Information  Technology  Architectures 

01  May  00 

AF 133-133 

Joint  Technical  Architecture  -  Air  Force 

01  July  00 

AFI 33401 

Air  Force  Information  Technology  Portfolio  Management  and  IT 

Investment  Review 

14  Mar  07 

AFPD  334 

Enterprise  Architecting 

27  Jun  06 

Document  No 

Standards  Title 

Issue 

DI-MGMT-  81644A 

DoD  Architecture  Framework  Documentation 

10  Nov  08 

SMC-S-001 

Systems  Engineering  Requirements  &  Products 

12  July  10 

Document  No 

Guidance  Title 

Issue 

DoDAF  2.0 

Department  of  Defense  Architecture  Framework  2.0  Volumes,  f  2, 3 

28  May  09 

DAU  DAG 

Defense  Acquisition  Guidebook 

05  May  10 

DoD  Enterprise  Architecture  Federation  Strategy  Draft  Version  1.01 

04  Dec  06 

DISR 

https :  //www.  disronl  ine .  disa.  mil 

FORCE  net  Service  Descn  ption  Framework  Version  2.0 

30  Mar  07 

Federal  Architecture  Framework  Documentation 

SMC-G-001 

Systems  Engineenng  Implementation  Guide 

17  Apr  09 

SMC-G-XXX 

Architecture  Development  &  Management  Guide  (Interim) 

24  Dec  09 

UML 

Unified  Modeling  Language  at  http://www.uml.org/ 

SysML 

Systems  Modeling  Language  at  http://www.sysml.org/ 

Architecture  Contributions  to  the  Acquisition  Life  Cycle  Framework 

The  DoD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  Architecture  Engineering  contributions  over  this 
life  cycle  are  best  represented  within  the  phases  of  the  Defense  Acquisition  Management  System.  Figure  14 
provides  the  acquisition  life  cycle  framework  within  which  the  Architecture  Engineer  performs  as  well  as  the 
products  that  the  Architecture  Engineer  must  develop  or  contribute  to  their  development.  This  figure  supports 
pre  and  post  contract  award  acquisition  activities,  and  performs  integrated  architecture  management  and 
engineering  across  the  system  lifecycle.  The  Program  Office  Architecture  Engineer  establishes  and  implements 
arcliitecture  program  strategies  and  objectives  consistent  with  the  tenets  of  applicable  policies,  SMC 
acquisition  objectives,  and  program  objectives.  The  Architecture  Engineer  then  develops,  attains  approval  for, 
and  implements  architecture  planning  into  the  Systems  Engineering  Plan  (SEP)  and  higher  level  integrated 
planning  (e.g.,  IMP)  in  accordance  with  current  DoD  policy.  This  planning  will  be  firmly  based  on  program 
and  technical  objectives,  strategies,  DoD  mandates,  and  instructions. 


The  Program  Office  Arcliitecture  Engineer  supports  ail  of  the  major  acquisition  activities  through  the  full 
system  life  cycle  to  ensure  architecture  program  requirements  are  hilly  extended  to  all  contributing  contractors 
through  the  appropriate  contract  SOO  and  wrork  statement  language,  compliance  standards,  etc.  Kence,  the 
Architecture  Engineer  supports  RFP  development  by  providing  PWS  and  SOO  language,  deliverable 
requirements  (CDRLs.  Data  Item  Descriptions)  for  architecture  products  and  data,  and  contractual 
requirements  to  participate  iu  forums  that  advance  and  approve  the  architecture  artifacts.  The  Architecture 
Engineer  prepares  proposal  evaluation  criteria,  assists  to  evaluate  proposals  and  carries  out  contractor 
performance  assessments  during  contract  execution. 


The  planning  sufficiently  defmes  architecture  activities  and  products  to  achieve  the  architecture  and  overall 
program  objectives  and  requirements;  specifies  tasks  and  functions  to  be  performed,  timing  of  tasks,  resources 
required,  and  products  to  be  developed:  forms  the  basis  for  the  development  of  the  Program  Office  Systems 
Engineering  Operating  Instruction  (01)  architecture  elements.  The  architecture  pi  aiming  and  QI  will  be 
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reflected  appropriately  in  the  WBS,  IMS,  and  other  program  documents  that  address  architecture  related 
elements.  The  a rclii lecture  planning  is  executed  concurrently  with  the  Program  Office  01  that  documents  the 
process  to  perform,  control,  and  integrate  all  architecture  engineering  and  management  activities  for  each 
phase  of  acquisition.  Program  office  architecture  planning  (usually  contained  in  the  SEP  and  the  detailed 
architecture  program  planning)  and  OI  will  also  be  based  upon  the  appropriate  program-approved  life  cycle. 
SMC  Program  Offices  appoint  establish  and  implement  Arcliitecture  program  strategies  and  objectives 
consistent  with  the  tenets  of  appropriate  policies,  SMC  acquisition  objectives,  and  program  objectives. 


MSA  Phase  -  SMC  Acquisition  Products 


PMD 


IDS,  DMS'TES 


1.  Materiel  Solution  Analysis.  During  this  phase,  the 
Architecture  Engineer  provides  inputs  to  and  supports 
most  program  acquisition  activities  to  include  the 
development  of  the  acquisition  strategy,  inputs  to  the  cost 
estimates,  solicitation/RFP  development  for  Contractor 
studies,  and  proposal  evaluation  activities.  The 
Architecture  Engineer  also  contributes  to  the  development  of  the  acquisition  MSA  Phase  products. 


LC  Cost  Estimate 


RFF  inputs  (Concepts,  OVs) 


APB,  CCA 


SSP,  SEP 


2.  Technology  Development.  The  Arehitectiue  Engineer 
provides  inputs  to  and  supports  all  program  acquisition 
activities  to  include  the  development  of  the  acquisition 
strategy,  technology  development  strategy,  development 
and  updates  to  the  cost  model  and  development  of  the 
Cost  .Analysis  Requirements  Description  (CARD). 
solicitation/RFP  development  and  proposal  evaluation 
activities.  The  Architecture  Engineer  establishes  the 
functional  and  the  physical  architecture  thereby  assisting 
Systems  Engineering  to  define  the  allocated  baseline. 


TD  Phase  —  SMC  Acquisition  Products 


ASP _ 

Updates  to  TPS,  QMS _ 

System  Cost  Model,  LC  Cost  Estimate  Update  /  CARD 
Development _ 

RFP:  Architecture  objectives  in  the  SOO;  Architecture 
related  tasks  in  SOWr  Architecture  task  requirements 
products  in  CDRLs;  SMC-  Architecture  Data  Item 
Description  -  tailored _ 

SSP:  evaluation  criteria  for  Architecture _ 

APB:  Arch  objectives  &  related  concept  descriptions 
Detailed  Arch  planning,  SEP,  LCMF;  TEMP,  ISP 


3. 


Engineering  <&  Manufacturing  Development.  The 
Architecture  Engineer  provides  inputs  to  and  supports  all 
program  acquisition  activities  to  include  updates  to  the 
acquisition  strategy  and  updates  to  the  cost  model  to 
reflect  the  actual  technical  solutions  detenniued  and 
updates  to  the  CARD.  The  Architecture  Engineer 
supports  the  soiicitation/RFP  development  and  proposal 
evaluation  activities  which  include  providing  the 


EMD  Phase  —  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS _ 

CARD  update _ 

REP:  SOO  architecture  objectives;  Sow  architecture 
tasks,  Architecture  products  in  CDRLs;  SMC- 
Architecture  Data  Item  Description-  tailored _ 

SSP:  evaluation  criteria  for  architecture _ 

APB:  architecture  objectives  concept  desenptions 

Architecture  planning,  SEP,  LCMP,  TEMP,  ISP 


teclmical  inputs  including  technical  requirements,  compliance  standards,  and  engineering  approaches  to 
meet  program  objectives.  Architect  contributes  to  the  development  and  updates  to  the  acquisition  products 


identified. 
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4*  Production  &  Deployment*  Operations  &  Support. 

The  Architecture  Engineer  provides  inputs  to  and 
supports  all  program  acquisition  activities  to  include 
updates  to  the  acquisition  strategy  and  updates  to  the  cost 
mode!  to  reflect  the  actual  technical  solutions  determined 
and  updates  to  the  CARD.  The  arclii  tec  hire  team  supports 
the  solicitation RFP  development  and  proposal  evaluation 
activities. 


Architecture  Contributions  to  the  Engineering  Life  Cycle  Framework 

Relationship  to  the  SE  Organization 

The  Architecture  Engineer  plans  and  executes  the  essential  architecture  development  and  management  efforts 
in  an  integrated  and  effective  manner  within  the  context  and  hill  support  of  the  overarching  Systems 
Engineering  (SE)  function.  The  Architecture  Engineer  ensures  that  each  of  their  SED  contributions  is  timely, 
adequate,  consistent,  and  compliant.  The  Architecture  Engineer  ensures  that  their  contributions  are  channeled 
through  the  Systems  Engineering  Analyses  and  Con  fro  I  activity. 

Systems  Engineers  manage  the  engineering  process  and  activities  depicted  in  Figure  3  while  the  Arcliitecture 
Engineer  contributes  to  this  process.  Architecture  engineers  perform,  manage,  and  support  the  concept  and 
arclii  tec  true  development  and  analyses;  modeling  and  simulation  efforts;  technology  studies.  The  Architecture 
Engineer  contributes  to  the  Systems  Engineering  process.  The  Architecture  Engineer  supports  concept  and 
arcliitecture  development  and  analyses;  modeling  and  simulations  efforts;  technology  studies;  decomposition 
of  design  trades;  interface  definition  and  decision:  and  integrated  arcliitecture  solutions.  As  well  as  supporting 
technical  and  program  management  activities  and  decision  making.  The  Architecture  Engineer  also  supports 
requirements  development  activities  and  requirements  analyses  by  creating  dynamic  system  models, 
abstractions  of  a  particular  domain  concept,  or  models  to  define  system  functions  then  allocate  and 
parameterize  requirements  to  perform  the  function. 

The  Architecture  Engineer  supports  the  system  trades  taking  into  aecomit  all  applicable  factors  to  ensure 
balanced  and  integrated  architecture  solutions.  The  Progr  am  Office  Architecture  Engineer  typically  participates 
and  supports  the  development  of  the  capability  viewpoints  (CVs)  and  the  operational  viewpoints  (QVs) 
developed  by  the  operator  and  user  organizations.  They  ensure  the  operating  and  using  organizations  are 
provided  an  opportunity  to  support  the  development  of  the  systems  viewpoints  (SVs),  services  viewpoints 
(SvcVs),  and  standards  viewpoints  (StdVs).  As  the  architectural  artifacts  are  developed,  the  architecture  team 
ensures  that  all  related  architecture  elements  (CV,  OV,  SV,  SvcV)  are  fully  mapped  in  a  relational  database, 
map  to  the  applicable  requirement  sets,  and  a  common  lexicon  of  architecture  elements  ar  e  documented  in  all 
viewpoints  (AV-2). 

The  architecture  development  process  must  be  integral  to  the  Systems  Engineering  process.  The  illustration 
below  provides  an  executable  architecture  development  process  that  inherently  produces  the  arcliitecture 
artifacts  as  an  output  of  the  Systems  Engineering  process,  and  to  ensure  the  architecture  products  are  then 
appropriately  vetted  and  leveraged  through  the  Systems  Engineering  organization  and  community  of 
stakeholders. 


P&D  /  O&S  Phase  -  SMC  Acquisition 
Products 


Updates  to  ASP,  TDSn  QMS _ 

CARD  update _ 

RFP:  Architecture  objectives  in  the  SCO,  Architecture 
related  tasks  in  SOW,  Architecture  lask  requirements 
products  in  CDRLs;  SMC-  Architecture  Data  Item 
Description-  tailored _ 

SSP:  evaluation  criteria  for  Architecture _ 

Architecture  planning,  SEP,  LCMP,  TEMP  updates 
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Figure  13  Architecture  development  executed  within  the  Systems  Engineering  process 
Relationship  to  other  SEDs 

The  Architecture  Engineer  SED's  relationship  to  other  SEDs  is  summarized  in  Figure  1.  The  Architecture 
Engineers  provide  functional  perspectives  for  reliability  and  safety  to  perform  their  failure  and  hazards 
analyses.  Use  case  Diagrams  to  support  the  software  engineers  and  Human  Systems  Integration  activities. 
Physical  perspectives  to  support  development  of  reliability  block  diagrams  and  configuration  specification 
trees. 

The  Arc hitec Hire  Engineer  works  with  the  Manufacturing  Engineers  to  assess  production  and  lay-outs:  works 
with  the  Logistics  Engineers  to  transform  functional  and  activity  diagrams  to  operations  and  field  processing 
flows. 


Tools  Selection  and  Use 

The  architecture  team  considers  effectiveness 
and  efficiencies  gained  by  selecting  and  using  the 
best  choice  of  architecture  engineering  tools 
considering  the  program  office  tools 
requirements  to  perform  modeling,  arcliitectural 
and  functional  analyses,  information  sharing,  automated  data  exchanges  with  other  tools,  and  other 
considerations. 


Architecture  Functions  Requiring  Tools 


Architecture  Modeling _ 

Requirements  Analyses  &  Allocations 
Design  Trade  Studies  and  Data  Analysis 

System  Analysis 
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Engineering  Activities  and  Products  over  the  Life  Cycle 
The  following  subsections  summarize  Architecture  Engineer's  contributions  to  engineering  activities  and 
technical  products  by  DoD  acquisition  phase. 


1*  Materiel  Solution  Analysis*  During  this 
phase  the  Architecture  Engineer  may 
provide  inputs  to  and  support  the 
Capabilities  Based  Assessment  process  and 
the  JCIDS  process.  The  Program  Office 
Architecture  Engineer  contributes  to  the 
development  of  the  mission  and  operational 
concept  models  and  other  architecture 
artifacts.  The  Architecture  Engineer  also 
contributes  to  the  development  of  the  MSA 
Phase  technical  products. 


MSA  Phase  —  Teclinical  Products  Requir  ed 

SMC  Architecture 
Technical  Products 

Contributions  ro  Other 
Organizations’  Products 

High  level  performance  and 
sustainment  analyses 

Operational  Concepts 

Architecture  inputs  and  factors  for 
concept,  architecture,  technology 
studies,  and  trades 

AoA  Studies 

System  Architecture  Req’fs 
(draft) 

Initial  Capabilities  Doc  (ICD)  Dev 

Roadmap  inputs 

DoDAF  CVs,  OVs 

2*  Technology  Development*  During  this 
phase  the  Architecture  Engineer  continues  to 
provide  inputs  to  and  supports  the  JCIDS 
process  and  activities.  The  Architecture 
Engineer  also  supports  the  engineering 
activities  highlighted  within  the  box  titled 
Engineering  Activities  for  System  &  Segment 
Development  &  Design  Figure  14  to 
commence  system  definition  and 
development.  The  Architecture  Engineer 
contributes  to  development  of  technology  and  transition  roadmaps,  architectural  and  other  system  trades, 
and  engineering  analyses.  The  Architecture  Engineer  contributes  to  the  development  of  TD  Phase 
technical  products. 

3*  Engineering  &  Manufacturing 
Develop meut.  The  Architecture  Engineer 
continues  to  provide  inputs  to  and  support 
the  JCIDS  process.  The  Architecture 
Engineer  supports  the  engineering  activities 
liiglilighted  within  the  box  titled 
Engineering  Activities  for  Detailed  Design 
Figure  14  to  commence  detailed  systems 
definition  and  development.  The 
Architecture  Engineer  contributes  to 
development  of  architectural  and  other  system  trades  and  engineering  analyses.  The  Architecture  Engineer 
also  contributes  to  the  development  of  the  EMD  Phase  technical  products  and  completion  of  the  teclinical 
baseline  to  include  all  baselined  arcliitecture  products  and  data.  The  Architecture  Engineer  supports 


EMD  Phase  -  Te clime al  Products  Required 


SMC  Architecture 
Technical  Products 

Contributions  to  Other 
Organiza  tious  *  Pro  d  ucls 

Update  System  Concept 

Operational  Concepts 

Technical  Studies/  Trades 

Operational  Assessments 

System  Tech  Reqts,  TRD,  SRD, 
Spec,  ICDs;  Architecture 
allocations 

Capabilities  Production  Doc 
(CPD) 

Inputs  to  system,  production, 
fielding,  sustain  design  docs 

DoDAF  CVs,  OVs 

SVs,  SvcVs,  StdVs,  AVs, 

Architecture  inputs  to  ISP 

TD  Phase  -  Technical  Pr o ducts  Required 

SMC  Architecture 
Technical  Products 

Contributions  to  Other 
Organizations^  Products 

inputs  to  System  Concepts 

Operational  Concepts 

Factors  for  Studies/  T rades 

Operational  Assessments 

Architecture  Tech  Req’ts,  TRD, 
SRD,  Specifications,  ICDs, 
Standards  Selection/  Tailor 

Capabilities  Development  Doc 
(CDD) 

Architecture  inputs  to  ISP 

DoDAF  CVs,  OVs 

SVs,  SvcVs,  StdVs,  AVs, 

Architecture  Analyses  Rpts 
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prototype  testing,  qualification  testing,  DT&E  as  directed  by  the  Systems  Engineering  Lead  to  ensure 
interoperability,  integration  and  other  requirements  assigned  to  the  architecture  discipline  are  met. 

4.  Production  &  Deployment,  Operations  & 

Support*  The  Architecture  Engineer 
continues  to  provide  inputs  to  and  supports 
the  JCIDS  process.  The  activities  of  the 
Architecture  Engineer  during  this  phase  are 
extensive.  The  Architect  maintains  the 
baselined  architecture  products  and  data  that 
are  essential  during  the  P&D  /  O&S  Phases. 

The  Architecture  Engineer  supports  GT&E 
as  directed  by  the  SE  Lead  to  ensure 
interoperability,  integration  and  other  requirements  assigned  to  the  architecture  discipline  are  met. 

Architecture  Contributions  to  Program  and  Project  Management 

Each  program  office  defines  their  business  model  and  business  approach  structure  based  primarily  on  their 
program  objectives,  program  and  teclinical  challenges,  organizational  structure,  as  well  as  program  and 
engineering  planning.  The  Architecture  Engineer  supports  the  program  management  activities  to  support  IPT 
and  program  level  management  decisions,  to  contribute  to  the  risk  management  process,  to  provide  cost  models 
for  cost  estimating  and  budget  planning,  to  assist  and  develop  roadmaps  to  define  future  states  of  a  system, 
e.g..  To-Be,  Objective  States,  and  to  evolve  systems  to  achieved  pre-pl aimed  incremental  capabilities. 

The  Architecture  Engineer  develops  and  implements  the  Architec tme  program  planning  to  achieve  arcliitecture 
objectives  and  requirements.  The  planning  defines  the  architecture  tasks  and  functions  to  be  performed; 
products  to  be  developed;  and  tuning  of  tasks,  task  outputs,  resources  (skills,  tools,  equipment,  and  completion 
criteria).  The  Architecture  Engineer  plans  tasks  to  integrate  arcliitecture  activities  within  the  program  office 
between  contractors  and  community  stakeholders.  The  Arcliitecture  Engineer  plans  the  tasks  to  establish  and 
manage  operational  architecture  viewpoints,  systems  architecture  viewpoints,  support  SE&I  activities,  e.g., 
system  design,  design  and  requirements  traceability,  V&V  activities,  risk  management,  internal  and/or  external 
interfaces,  integration,  and  system  modifications;  coordinate  the  architec  tine  planning  with  Systems 
Engineering,  operating  commands,  supporting  commands,  and  test  agencies;  and  integrate  architec ture 
planning  with  other  functional  and  acquisition  plans  (i.e.  SEP.  ASP.  LCMP). 

Execution  of  the  architecture  planning  is  typically  defined  through  an  Operating  Instinct  ion  (OI).  The 
Arc  lute  c  Hire  Engineer  provides  fiill  support  to  define  the  program  and  teclinical  objectives  where  architectural 
challenges  and  risks  are  known  or  anticipated.  The  architecture  team  assists  establishing  the  business  model, 
developing  program  planning  and  schedules,  and  defining  and  implementing  program  processes.  The 
Architecture  Engineer  ensures  the  architecture  development  and  management  components  of  the  program  are 
appropriately  represented  in  the  program  plans,  program  schedules,  work  breakdown  schedules,  and  cost 
estimates.  The  Architecture  Engineer  reports  their  teclmical  performance  and  progress.  The  Architecture 
Engineer  sliares  in  the  risk  management  responsibilities  to  identify,  assess,  and  propose  mitigating  actions  of 
their  related  risks.  The  Architecture  Engineer  also  supports  the  program  manager's  problem  identification, 
resolution,  and  decision-making  processes. 


P&D !  O&S  Phase  -  Technical  Products  Required 


SMC  Architecture 

Technical  Products 

Contributions  to  Other 
Organizations’  Products 

Inputs  tech  baseline  engineering 
changes 

Sup  portability  Analyses  Rpt 

Analyses  of  production  quality 
reports  and  test  reports 

Operational  Assessments 

Inputs  to  Transition  &  Fielding 
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Architecture  Models 
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Appendix  K  -  System  Safety  Engineering 

Systems  Safety  Engineering  is  a  well  -defined  and  established  SMC  discipline  and  it  is  one  of  the  engineering 
disciplines  inherent  in  the  multi-disciplined  Environment,  Safety  and  Occupational  Health  (ESOH)  subject 
area.  Sufficient  instructions,  guidance,  and  senior  expert  SMC  Staff  resources  are  available  to  assist  the 
Program  Office  System  Safety  Manager/Engineer  (SSM)  in  establishing  and  executing  a  System  Safety 
Engineering  program.  The  SSM  plans  and  executes  the  essential  system  safety  engineering  and  management 
efforts  in  an  integrated  and  effective  maimer  to  ensure  that  each  system  safety  SED  contribution  is  timely, 
adequate,  consistent,  and  compliant.  The  SSM  ensures  that  their  engineering  contributions  are  channeled 
through  the  Systems  Engineering  Analyses  and  Con  fro  I  activity. 

Applicable  governance,  standards,  and  guidance 

Policy,  directives,  and  instructions  that  mandate  SMC  system  safety  engineering  related  program  requirements 
are  included  in  a  wide  range  of  mandates.  Requirements  ar  e  applied  throughout  program  life  cycle  of  all  SMC 
acquisition  programs  and  projects  (existing  and  hi  Hue  SMC  space  systems)  that  involve  design,  development, 
modification,  evaluation,  demonstration,  testing,  operation  and  disposal. 

DoDI  5 GOO.  02,  AFI  63-101,  AFI  63-1201 AFI  9 1 -202  AFSPCSUP  I,  AFI  91-217,  and  SMCI  63-1205  system 
safety  related  mandates  for  SMC  acquisition  programs  include: 

1.  The  Program  Manager  (PM)  or  Program  Support  Manager  (PSM),  Lead  Systems  Engineer  /  Chief 
Engineer,  and  System  Safety  Manager/Engineer  (SSM)  ensure  that  appropriate  Human  Systems 
Integration  (HSI)  and  ESOH  efforts  are  integrated  across  disciplines  and  into  Systems  Engineering  to 
determine  system  design  characteristics  that  can  (1)  minimize  or  eliminate  the  risks  of  system  related 
mishaps:  acute  or  chronic  illness,  disability,  or  death  or  injury  to  operators  and  mamtainers;  and  (2) 
enhance  job  performance  and  productivity  of  the  personnel  who  operate,  maintain,  or  support  the 
system. 

2.  The  SSM  ensures  the  T&E  strategy  addr  esses  system  safety  in  the  development  and  assessment  of  the 
weapons  support  equipment  during  the  EMD  Phase,  and  into  production,  to  ensure  satisfactory  safety  of 
activities  associated  with  test  system  measurement  performance,  calibration  traceability  and  support, 
requir  ed  diagnostics,  and  requir  ed  system  safety  testing.  The  PM  or  PSM.  in  conceit  with  the  user  and 
the  T&E  community,  provides  safety  releases  (to  include  fonnal  Envir  onment  Safety,  and  Occupational 
Health  (ESOH)  risk  acceptance)  to  the  developmental  and  operational  testers  prior  to  any  test  using 
personnel.  Dining  DT&E  the  development  contractor  must  assess  the  safety  of  the  sy stem/ item  to  ensur  e 
safety  during  Operational  Test  (OT)  and  other  hoop -supported  testing  and  to  support  success  in  meeting 
design  safety  criteria. 

3.  The  SSM  supports  the  PM  or  PSM  and  Program  HSI  Engineer  to  take  steps  (e.g.,  contract  deliverables 
and  Government/contractor  IPT  teams)  to  ensure  ergonomics,  human  factors  engineering,  and  cognitive 
engineering  is  employed  during  Systems  Engineering  over  the  life  of  the  program  to  provide  for 
effective  human-machine  interfaces  and  to  meet  HSI  requirements.  Where  practicable  and  cost  effective, 
system  designs  shall  minimize  or  eliminate  system  characteristics  that  require  excessive  cognitive, 
physical,  or  sensory  skills;  entail  extensive  training  or  workload -intensive  tasks;  result  hi  mission- 
critical  errors:  or  produce  safety  or  health  hazards. 
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4.  The  SSM  ensures  integration  of  ESOH  risk  management  into  the  overall  Systems  Engineering  process 
for  all  developmental  and  sustaining  engineering  activities.  As  part  of  risk  reduction,  the  SSM  supports 
the  PM  or  PSM  to  eliminate  ESOH  hazards  where  possible,  and  manage  ESOH  risks  where  hazards 
cannot  be  eliminated.  For  SMC  programs,  the  SSM  uses  the  methodology  in  MIL-STD-882.  The  SSM 
reports  on  the  status  of  ESOH  risks  to  the  PM  or  PSM  who  will  report  acceptance  decisions  at  technical 
reviews.  The  PM  or  PSM  ensures  the  acquisition  program  reviews  and  fielding  decisions  address  the 
status  of  all  high  and  serious  risks,  and  applicable  ESOH  technology  requirements.  Prior  to  exposing 
people,  equipment,  or  the  environment  to  known  system-related  ESOH  hazards,  the  SSM  assists  the  PM 
or  PSM  to  document  that  the  associated  risks  have  been  accepted  by  the  following  acceptance 
authorities:  the  CAE  for  high  risks,  PE O -level  for  serious  risks,  and  the  PM  or  PSM  for  medium  and  low 
risks.  The  User  representative  shall  be  part  of  this  process  throughout  the  life  cycle  and  shall  provide 
formal  concurrence  prior  to  all  serious-  and  high-risk  acceptance  decisions. 

5.  The  PM  or  PSM,  regardless  of  program  ACAT  level  shall  prepare  a  Programmatic  Environment,  Safety 
and  Occupational  Health  Evaluation  (PE  SHE)  which  incorporates  the  ML -STD-8  82  process  addressing 
(1)  Identification  of  ESOH  responsibilities,  (2)  Strategy  for  integrating  ESOH  considerations  into  the 
systems  engineering  process.  (3)  Identification  of  ESOH  risks  and  their  status,  (4)  Description  of  the 
method  for  tracking  hazards  tlnoughout  the  life  cycle  of  the  system,  and  (5)  Identification  of  hazardous 
materials,  wastes,  and  pollutants  associated  with  the  system  and  plans  lor  then  minimization  and/or  safe 
disposal. 

6.  System  Safety  Management  Plan  (SSMP)  and  PESHE  Schedules.  The  PESHE  shall  be  developed  to 
support  milestone  decisions  (MS)  with  an  initial  submittal  at  MS-B  and  updated  at  MS-C  and  Full -Rate 
Production  (or  Full  Deployment)  Decision  Review  (DR).  Adequate  lead  time  will  be  considered  when 
contracting  out  data  deliverables  required  as  data  source  for  the  PESHE.  The  PESHE  document  must  be 
coordinated  by  SMC/SE  and  SMC/EN.  signed  by  the  Systems  Director  and  approved  by  the  appropriate 
management  authority  prior  to  the  MS  decision  it  supports.  The  SSMP  and  PESHE  program  schedules 
and  activities  will  correspond  and/or  complement  each  other. 

7.  SSG.  SSWG  and  PESHEWG.  A  System  Safety  Group  (SSG)  SSG  must  be  established  for  all  SMC 
acquisition  programs  and  projects.  It  applies  to  Acquisition  Category  I  (ACAT  1)  or  equivalent 
programs  and  to  all  SMC  missile  launch  vehicle,  satellites  and  ground  facilities  unless  waived  by 
AFSPC/SES  through  SMC/SE.  The  SSG  will  be  the  method  used  by  senior  leadersliip  to  provide 
guidance  and  oversight  to  the  SD's  system  safety  progr  am.  The  Systems  Dir  ector.  PM  or  PSM  or  the 
Deputy  PM  or  PSM  will  chair  the  SSG.  The  SSG  will  be  responsible  for  (1)  evaluating  the  program 
System  Safety  status  including  funding,  (2)  ensuring  all  appropriate  managers  consider  and  document 
the  residual  risks  of  hazards,  (3)  reviewing  the  analyses  of  major  safety  design  trade-offs  and 
modifications.  These  analyses  will  include  hazard  risk  descriptions,  proposed  corrective  actions  and 
their  effect  and  current  status,  (4)  reviewing  the  status  of  planned,  pending,  active,  and  disapproved 
safety  modifications,  (5)  reviewing  and  possibly  approving  or  disapproving  selected  hazard  analysis  and 
then  recommended  controls  and  verification,  and  (6)  reviewing  high  accident  potential  reports. 

a.  System  Safety  Working  Group  (SSWG).  The  SSWG  will  be  established  by  the  SSG  to  work 
detailed  safety  issues.  The  SSWG  will  be  chaired  by  the  SSM  and  typical  activities  include 
assessing  the  status  of  safety  activities  in  the  total  system,  various  system  segments,  elements, 
subsystems  and  components.  Hazards  and  their  mitigations  will  be  reviewed  arid  disposed  where 
ill-defined  hazards  will  be  returned  to  the  originator  for  clarification  and  where  valid  hazards  for 
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which  mitigation  proposals  have  not  been  made  will  be  assigned  to  an  action  officer,  for 
mitigation. 

b.  Programmatic  ESOH  Evaluation  (PE SHE).  Early  in  Pre- Systems  Acquisition,  the  SSM  will 
ensure  that  the  charter  for  the  PE  SHE  Working  Group  (PESHEWG)  will  be  drafted,  coordinated, 
finalized  and  approved  for  implementation  at  the  ID  phase.  The  SSM  will  also  ensure  that 
appropriate  membership  and  activities  are  cited  in  the  PESHEWG  charter.  Typical  membership 
includes  organizational,  environment  and  health  representatives  hi  addition  to  system  safety.  The 
SSM  may  also  be  tasked  by  the  PM  or  PSM  to  write  and  oversee  the  coordination  and  completion 
of  the  PE  SHE  document.  The  SSM  is  a  key  person  in  the  establishment  and  activation  of  the 
PESHEWG. 

8.  Space  Debris  Assessment  Report  (SDAR)  and  End  of  Life  Plan  (EOLP).  The  SSM  will  ensure  that 
required  system  safety  related  assessments  and  data  submittals  supporting  operations  and  end-of-life 
actions  are  also  included  as  contract  data  deliverables.  These  data  include  the  Space  Debris  Assessment 
Report  (SDAR)  and  End -of- Life  Plan  (EOLP).  The  SSM  will  also  provide  input  to  the  contact  to  ensure 
the  timely  delivery  of  these  data.  For  example,  a  PDR  Draft  SDAR  is  required  30  days  before  PDR  and  a 
CDR  Draft  SDAR  is  required  45  days  before  CDR. 

9.  Design  and  Disposal.  Design  and  disposal  plans  shall  be  delineated  hi  the  SSMP.  At  the  end  of  its  useful 
life,  a  system  will  be  demilitarized  and  disposed  of  in  accordance  with  all  legal  and  regulatory 
requirements  and  policy  relating  to  safety  (including  explosives  safety),  security,  and  the  environment. 
Disposal  will  take  into  consideration  space  debris  and  public  safety  risk  minimization  or  elimination. 
During  the  design  process,  PMs  or  PSMs  must  document  (in  the  PE  SHE)  hazardous  materials  contained  in 
the  system  and  will  estimate  and  plan  for  the  system's  demilitarization  and  safe  disposal. 

a.  End  of  Life  Disposal,  Programs  shall  develop  appropriate  disposal  plans  for  orbital  space  systems 
to  either  to  reenter  the  atmosphere  safely  or  else  be  moved  into  a  disposal  orbit  at  the  end  of  its 
usefhl  where  it  will  be  less  likely  to  interfere  with  operational  spacecraft.  Programs  will  provide 
an  EOLP  for  the  disposal  of  the  space  system  at  the  end  of  its  use  fill  life.  Effective  disposal  of 
nonfunctional  space  systems  not  only  provides  an  immediate  benefit  by  protecting  operational 
spacecraft  from  accidental  collisions  with  orbital  debris,  but  also  has  the  long-term  benefit  of 
reducing  the  probability  of  nonfhnctioning  objects  colliding  with  one  another  and  creating 
additional  debris, 

10.  Mishap  Investigation  Support.  PMs  or  PSMs  shall  support  system-related  Class  A  and  B  mishap 
investigations  by  providing  analyses  of  hazards  that  contributed  to  the  mishap  and  recommendations  for 
materiel  risk  mitigation  measures,  including  those  that  minimize  human  errors  in  accordance  with  AFI  91  - 
204 ,  “Safety  Investigation  and  Reports  A  24  September  2008  and  .AFI  91-222  AFSPC  Supplement  2 
January  2007,  Space  Safety  Inv  estigation  and  Reports.1'  Once  the  Convening  Authority  accepts  the  Safety 
Investigation  Board  (SIB)  or  Single  Investigator  (SIO)  final  report  that  contains  findings, 
recommendation,  other  findings  of  significance  (OFS)  and  other  recommendations  of  significance  (ORS), 
the  System  Safety  Manager  will  assist  in  implementing  the  recommendations  and  ORS  to  achieve  closure 
conditions  and  closure  dates.  This  will  ensure  prevention  of  furore  space  mishaps. 

11.  Deficiency  Reporting,  Investigation,  And  Resolution,  SSMs  must  be  fiilly  trained  and  qualified  to 
effectively  implement  and  participate  in  the  USAF  Deficiency  Reporting  and  Investigating  System 
(DRIS).  This  system  promotes  the  ability  to  identify  and  correct  deficiencies  before  they  impact  mission 
capability;  thus,  promoting  Operational  Safety.  Suitability  and  Effectiveness  (OSS&E). 
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Table  16  below  identifies  the  significant  governance,  standards,  and  guidance  which  generally  require  SMC 
compliance  for  System  Safety  Engineering. 


Table  16  Governance,  standards,  anti  guidance  that  shape  the  System  Safety  Engineering  discipline 


Document  No 

Governance  Title 

Issue 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

CJCSM  3170.01 

Operation  of  the  Joint  Capabilities  Integration  and  Development 

System 

24  Jun  03 

DoDI  6055.1 

Dcu  Safety  and  Occupational  Health  (SOH)  Program 

19  Aug  98 

DoDI  6050.05 

DoD  Hazard  Communication  Program 

15  Aug  06 

DoDI  6055.06 

DoD  Fire  and  Emergency  Services 

21  Dec  06 

DoDI  6055.07 

Accident  Investigation,  Reporting  and  Record  Keeping 

03  Oct  00, 

Chq  1  24  Apr  08 

AFI 63-101 

Acquisition  and  Sustainment  Life  Cycle  Management 

22  Mar  11 

AFI 63-1201 

Life  Cyde  Systems  Engineering 

23  Jul  07 

DoDD  4715.1  E 

Environment,  Safety,  and  Occupational  Health 

19  Mar  05 

DoDD  6055.9E 

DoD  Explosives  Safety  Management  and  the  DoD  Explosives  Safety 
Board 

19  Aug  05 

AFI  91- 

The  US  Air  force  Mishap  Prevention  Program 

01  June  05,  Certified 

202 AFSPCSUP I 

Current  30  July  07 

AFI  91- 

204  AFSPCSUP  1 

Safety  Investigations  and  Reports 

02  Jan  07 

AFI  91-217 

Space  Safety  and  Mishap  Prevention  Program 

18  Feb  10 

SMCI 63-1205 

Space  Systems  Safety  Policy,  Process,  and  Techniques 

20  Aug  07 

Document  No 

Standards  Title 

Issue 

MIL-STD-882C 

System  Safety  Program  Requirements 

19  Jan  93  1 

MIL-STD-882D 

Department  of  Defense  Standard  Practice  For  System  Safety 

10  Feb  00 

AFSPCMAN  91-710 

Range  Safety  User  Requirements  Manual 

01  Jul  04 

AFSPCMAN  91-711 

Launch  Safety  requirements  for  Air  Force  Space  Command 
Organizations 

01  Feb  07 

AFMAIN  91-201 

Explosives  Safety  Standards 

12  Jan  11 

AFMAN  91-222 

Space  Safety  Investigations  and  Reports 

09  Aug  05 

TO  0O-35D-54 

USAF  Deficiency  Reporting,  Investigation,  and  Resolution 

01  Jul  04,  Chg  1 15 

Mar  06 

Document  No 

Guidance  Title 

Issue 

Air  Force  System  Safety  Handbook 

Jul  00 

CPATS 

Critical  Process  Assessment  Tod  -  Safety  Engineering 

14  Aug  98 

Software  System  Safety  Handbook 

Dec  99 

SMC  Programmatic  Environmental,  Safety,  And  Health  Evaluation 
(PESHE)  Guide 

25  Feb  02 

ANSI/GEIA-STD-0010 

Standard  Best  Practices  for  System  Safety  Program  Development  and 
Execution 

12  Feb  09 
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The  list  of  data  Item  Descriptions  (DIDs)  provided  below  correlate  with  Mil  STD  8S2  data  deliverables.  SMCI 
63-1205  provides  the  associations  of  these  and  additional  DIDs  with  MIL-STD-882  as  well  as  recommended 
tailoring. 


Date  Item  Title 

Date  Item  Description  (DID) 

System  Safety  Program  Plan  (SSPP) 

D  l-S  AFT-8 1626 

System  Safety  Hazard  Analysis  Report  (SSHAR) 

DI-SAFT-80101B 

Safety  Assessment  Report  (SAR) 

D  !-S  AFT-80 1 02 B  j 

Engineering  Change  Proposal  System  Safety  Report  (ECPSSR) 

DI-SAFT-80103B 

Waiver  or  Deviation  System  Safety  Report  (WDSSR) 

D  !-S  AFT  -80 1 04 B 

System  Safety  Program  Progress  Report  (SSPPR) 

D  [-S  AFT-80 1 05 B 

Health  Hazard  Assessment  Report  (HHAR) 

D  i-S  AFT  -80 1 06 B 

Mishap  Risk  Assessment  Report  (MRAR) 

DI-SAFT-81300A  \ 

Explosive  Hazard  Classification  Data 

D  l-S  AFT-8 1 299 B 

Flight  Termination  System  Report  (FTSR) 

DI-SAFT-80183A 
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System  Safety  Engineers'  Contributions  to  the  Acquisition  Life  Cycle 
Framework 

The  DgD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  System  Safety  contributions  over  this  Life  cycle 
are  best  represented  within  the  phase  of  acquisition.  Figure  1 5  provides  the  acquisition  life  cycle  framework 
within  which  SSMs  perform  as  wrell  as  the  products  that  the  SSMs  develop  or  contribute  to  their  development. 
This  figure  along  with  SMCI  63-1205,  provide  requirements  to  perform  System  Safety  planning,  support  pre 
and  post  contract  award  acquisition  activities,  and  perform  System  Safety  management  and  engineering  across 
the  system  lifecycle.  SMC  Program  Offices  establish  and  implement  System  Safety  program  strategies  and 
objectives  consistent  with  the  tenets  of  appropriate  policies,  SMC  acquisition  objectives,  and  program 
objectives.  The  Program  Office  develops,  attains  approval  for,  and  implements  System  Safety  planning  into  the 
System  Safety  Management  Plan  (SSMP)  and  higher  level  integrated  planning  (e.g.,  IMP)  in  accordance  with 
current  DoD  policy.  Tins  planning  is  firmly  based  on  program  and  technical  objectives,  strategies,  DoD 
mandates,  and  instructions. 

Ail  effective  System  Safety  program  supports  all  of  the  major  acquisition  activities  through  the  full  system  fife 
cycle.  The  planning  sufficiently  defines  the  System  Safety  program  to  achieve  the  Safety  and  overall  program 
objectives  and  requirements;  specifies  tasks  and  functions  to  be  performed,  timing  of  tasks,  resources  required, 
and  products  to  be  developed:  forms  the  basis  for  the  development  of  the  program  System  Safety  Management 
Plan  (SSMP).  The  Safety  planning  and  SSMP  are  then  reflected  appropriately  in  the  ASD,  RFP,  SEP,  TEMP, 
KSIP.  ILSP.  and  other  program  documents  that  address  Safety  related  elements.  The  requirements  of  the 
SSMP  must  also  be  flowed  down  to  the  Contractor's  System  Safety  Program  Plan  (SSPP)  and  other  Contractor 
data  deliverables  including  the  WBS  and  IMP.  The  Safety"  planning  is  executed  concurrently  with  the  SSMP 
that  documents  the  process  to  perform,  control,  and  integrate  all  Safety  engineering  and  management  activities 
for  each  phase  of  acquisition.  The  SMC  Program  Office's  SSMP  is  also  based  upon  the  appropriate  program  - 
approved  life  cycle.  The  following  subsections  delineate  System  Safety  contributions  to  acquisition  activities 
and  products  by  DoD  acquisition  Phase.  Refer  to  SMCI  63-1205  for  a  more  complete  fist  of  System  Safety 
activities  and  products  that  are  prepared  by  the  Program  office  and  their  Contractors. 
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1.  Materiel  Solution  Analysis.  During  this  phase  the  SSM 
provides  inputs  to  and  supports  most  program  acquisition 
activities  to  include  the  development  of  the  acquisition 
strategy,  inputs  to  the  cost  estimates,  solid tation/RFP 
development  for  Contractor  studies,  and  proposal 
evaluation  activities.  The  SSM  prepares  a  draft  System 
Safety  Management  Plan  (SSMP)  and  also  contributes  to 
the  development  of  the  MSA  Phase  acquisition  products. 


MSA  Phase  -  SMC  Acquisition  Products 


PMD _ 

ASP,  TPS,  DMS,  TES 

LC  Cost  Estimate _ 

RFP  inputs  (operations  &  system  safety  requirements; 
Safety  assessment  requirements;  High  level  Safety 
assessments  of  concepts,  CDRL,  PHL,  proposal 
evaluation  criteria,  contract  language) _ 

APB,  CCA _ 

Draft  SSMP,  SSG/SSWG  Charters _ 

J CMF  


TD  Phase  —  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS 


LC  Cost  Estimate  Update  /  CARD  Development 


RFP:  Safety  objectives  in  the  S00;  Safety  related 
tasks  in  SOW,  Safety  data  products  in  CDRLs  (SSPPr 
PHAR;  SMC-  Safety  standards  -  tailored 


2.  Techuology  Development.  The  SSM  provides  inputs  to 
and  supports  all  program  acquisition  activities  to  include 
the  development  of  the  acquisition  strategy,  updates  to 
the  cost  model  and  development  of  the  Cost  Analysis 
Requirements  Description  (CARD).  solicitation/REP 
development  and  proposal  evaluation  activities.  The  SSM 
identifies  other  contract  requirements  such  system  safety 
requirements,  safety  related  tasks,  test  demo 
requirements  to  meet  Safety  objectives.  The  SSM  also 
contributes  to  the  development  and  updates  to  the  TD  Phase  acquisition  products  to  include  the 
review/ comment  appro  va  1  of  system  safety  data  deliverables. 


SSMP  update;  PESHE,  Draft  SPAR  &  EQLP, 


APB:  Safety  objectives  &  related  concept  descriptions 


Detailed  Safety  planning  (SSMP),  SEP,  LCMP,  TEMP, 
HSIP 


EMD  Phase  —  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS 


CARD  update 


RFP:  Safety  objectives  in  the  S00;  Safety  related 
tasks  in  SOW,  Safety  data  products  in  CDRLs  (SSHA, 
SHA,  O&SHA):  SMC-  Safety  standards  -  taifored 


SSMP;  PESHE  SOAR,  EOLP 


3.  Engineering  &  Manufacturing  Development.  The  SSM 
provides  inputs  to  and  supports  all  program  acquisition 
activities  to  include  updates  to  the  acquisition  strategy 
and  updates  to  the  cost  model  to  reflect  the  actual 
technical  solutions  determined  and  updates  to  the  CARD. 

The  SSM  supports  the  solicitation/RFP  development  and 
proposal  evaluation  activities  which  include  providing  the 
technical  inputs  including  technical  requirements, 
compliance  standards.  engineering  approaches, 
incentives,  and  warranty  programs  to  meet  program  objectives.  The  SSM  identifies  other  contract 
requirements  as  necessary  to  meet  System  Safety  objectives.  The  SSM  also  contributes  to  the  development 
and  updates  to  the  EMD  Phase  acquisition  products  winch  includes  the  review/ comment/ approval  of 
system  safety  data  deliverables. 


APB:  Safety  objectives  &  related  concept  descriptions 


Detaifed  Safety  planning,  SEP,  LCMP,  TEMP,  HSIP 
updates 


During  EMD  the  SSM  ensures  that  hazardous  materials  are  documented  in  the  Programmatic 
Environment,  Safety,  and  Occupational  Health  Evaluation  (PESHE)  and  ensures  that  the  SMC  Program 
Office  estimates  and  plans  for  the  system's  demilitarization  and  safe  disposal.  The  demilitarization  of 
conventional  ammunition  (including  any  item  containing  propellants,  explosives,  or  pyrotechnics)  must  be 
considered  during  system  design. 


S v tern  Safe ty  SMC  Sped  a l fy  Ei igi n eeri i ig  Disciplines  145 

4.  Production  &  Deployment,  Operations  &  Support* 

The  SSM  provides  inputs  to  and  supports  all  program 
acquisition  activities  to  include  updates  to  the  acquisition 
strategy  and  updates  to  the  cost  mode!  to  reflect  the  actual 
teclmical  solutions  determined  and  updates  to  the  CARD. 

The  SSM  supports  the  sohcitation/RFP  development  and 
proposal  evaluation  activities.  The  SSM  identifies  other 
contract  requirements:  production  and  field  test  &  demo 
requirements :  field  performance  and  sustainment  analyses 
to  meet  system  safety  objectives.  At  the  end  of  the  system’s 
demilitarized  and  disposed  of  in  accordance  with  legal  and 
ESOH. 

System  Safety  Engineers’  Contributions  to  Engineering  Life  Cycle 
Framework 

Relationship  to  the  SE  Organization 

The  SSM  plans  and  executes  the  essential  system  safety  engineering  and  management  efforts  hi  an  integrated 
and  effective  maimer  within  the  context  and  full  support  of  the  overarching  Systems  Engineering  function.  The 
SSM  ensures  that  then  SED  contributions  are  timely,  adequate,  consistent,  and  compliant  and  system  safety 
contributions  are  channeled  through  the  Systems  Engineering  Analyses  and  Comm  I  activity. 

Systems  Engineers  manage  the  engineering  process  and  activities  depicted  Figure  3  while  the  System  Safety 
Engineer  contributes  to  this  process.  System  Safety  Engineers  support  concept  and  architecture  development 
and  analyses:  modeling  and  simulation  efforts;  technology  studies.  The  System  Safety  Engineers 
develop/derive  safety  related  requirements  and  supports  the  requirements  analyses  and  allocations  process. 
They  also  participate  in  technical  studies  and  technical  solutions  trades  when  safety  is  a  factor.  They  provide 
design  analyses  contributions  to  determine  potential  hazards  and  safety  related  risks.  They  assess  and  propose 
alternative  mitigating  actions  or  solutions.  The  System  Safety  Engineer  also  works  closely  with  the  System 
Engineers  performing  interface  analyses  and  functional  analyses  to  leverage  the  required  safety  related 
analyses.  The  System  Safety  Engineer  also  supports  the  integration  and  verification  and  validation  planning 
and  execution. 

In  performing  the  management  and  control  function,  the  Systeius  Engineer  effectively  integrates  all 
engineering  functions  through  the  full  system  life  cycle.  The  System  Safety  Engineer  ensures  then  technical 
contribution  to  the  overall  engineering  advances  and  is  appropriately  applied  through  systematic  control, 
collaboration  and  sharing  across  the  organization.  For  example,  their  assessment  products,  e.g.,  hazards 
assessments  are  timed  to  coincide  with  architectural  trades,  design  trades,  r  eh  ability  analyses  (fault  tree, 
fishbone,  failure  modes,  critical  items  lists,  reliability  block  diagrams,  etc),  hi  addition  the  System  Safety 
Engineers  products  are  timed  and  applied  by  the  other  Specialty  Engineers  to  perform  their  unique 
contributions  (arid  vice  versa),  and  must  be  provided  to  technical  and  program  management  for  decision 
making. 


P&D  /  O&S  Phase  -  SMC  Acquisition 
Products 


Updates  to  ASP,  TPS,  DMS _ 

RFP:  Safety  objectives  in  the  S00;  Safety  related 
tasks  in  SOW,  Safety  data  products  in  CDRLs,  SMC- 
Safety  standards  -  tailored  _ 

Updates:  SSMP;  PESHE _ 

Detailed  Safety  planning,  SEP,  LGMP,  TEMP,  HSIP 
jpdaies _ 

CARD  update 

useful  life,  the  SSM  ensures  that  the  system  is 
regulatory  requirements  and  policy  relating  to 


System  Safety 
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Relationship  to  other  SEDs 

The  System  Safety  Engineer  SED  relationship  to  other  SEDs  is  summarized  in  Figure  1.  System  Safety 
interactions  with  the  other  SEDs  are  critical  to  perform  and  integrate  their  engineering  contributions  to  the 
system  development  efforts.  When  failure  analyses  results  indicate  potential  safety  impacts,  The  System  Safety 
engineer  assists  to  adjust  reliability  allocations  and  ensure  confidence  in  attaining  safety  requirements  through 
analyses,  demo,  and  test.  The  figure  below  illustrates  how  the  System  Safety  Engineer  performs  analyses  and 
integrates  that  effort  with  the  Systems  Engineer,  Reliability  Engineer,  and  Risk  Manager. 

The  System  Safety  Engineer  wTorks  closely  with  the  Logistics  Engineers  performing  maintenance  and 
sustainment  analyses  to  identify  and  address  safety  related  issues  or  risks.  The  System  Safety  Engineer  aligns 
closely  with  the  Quality  Assurance  and  Quality  Engineer  to  ensure  safe  operations  during  production, 
handling,  storage,  packaging,  and  transportation. 

Tools  Selection  and  Use 

The  System  Safety  Engineer  considers 
effectiveness  and  efficiencies  gained  by  selecting 
and  using  the  best  choice  of  safety  tools 
considering  rhe  safety  tool  requirements  possibly 
for  safety  /  hazards  analyses,  information 

sharing,  automated  data  exchanges  with  other  tools,  and  other  considerations. 


Typical  Safety  Functions  Requiring  Tool 


Hazards  identification,  analyses  &  reporting _ 

Incidents  &  action  tracking _ 

Fault  tree,,  failure  modes;  probabilistic  failure  analyses  (See  RAM  SEP) 
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Example  Safety  Engineering  Analyses  and  the  Essential  Interactions  with  Systems 
Engineer,  Reliability  Engineer,  and  Risk  Manager 
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Figure  16  Example  interaction  between  System  Safety,  Systems  Engineer,  Reliability  Engineer,  and  Risk  Manager 
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Svstem  Safety 


Engineering  Activities  and  Products  over  the  Life  Cycle 

Engineering  activities  that  are  unique  to  System  Safety  include: 

•  Identify,  evaluate,  and  control  system  safety  and  health  hazards  throughout  the  system’s  life  cycle. 

•  Define  and  document  mishap  risk  levels  including  associated  mishap  risk  acceptance  processes. 

•  Establish  a  program  that  manages  and  documents  the  probability  and  severity  of  all  hazards  associated 
with  development,  use  and  disposal  of  the  system. 

•  Manage  all  safety  and  health  risks  in  a  maimer  that  is  cost  effective  and  consistent  with  mission 
requirements. 

•  Ensure  that  space  safety  (launch  and  orbital  safety)  requirements  are  established  and  implemented  for 
all  space  systems.  Launch  safety  includes  launch  operations  safety,  flight  safety  analysis,  and  mission 
flight  control;  orbital  safety  covers  the  post-launch  phase  of  a  space  system  and  includes  the  control 
and  minimization  of  hazards  related  to  orbital  debris,  collision  avoidance,  laser  clearing-house 
functions,  environmental  hazards,  and  safety  procedures. 

•  Establish  an  explosives  safety  program  that  ensures  munitions,  explosives,  and  energetics  are  properly 
hazard  classified,  and  safely  developed,  manufactured,  tested,  transported,  handled,  stored, 
maintained,  demilitarized,  and  disposed.  Comply  with  DoD  explosives  safety  requirements  in  all 
acquisition  programs  that  include  or  support  munitions,  explosives,  or  energetics.  Evaluate  and 
manage  the  use  and  selection  of  energetic  materials  and  the  design  of  munitions  and  explosive 
systems  to  reduce  the  possibility  and  the  consequences  of  any  munitions  or  explosives  mishap  to 
optimize  the  trade-off  of  munitions  reliability  against  unexploded  ordinance  liability. 

The  following  subsections  delineate  System  Safety  contributions  to  engineering  activities  and  technical 
products  by  DoD  acquisition  phase.  Refer  to  SMCI  63-1205  for  a  more  complete  list  of  System  Safety 
activities  and  products  prepared  by  the  Program  Office  and  their  Contractors. 

1.  Materiel  Solution  Analysis.  During  this 
phase  the  System  Safety  Engineer  may 
provide  inputs  to  and  support  the 
Capabilities  Based  Assessment  process  and 
the  JCIDS  process.  The  System  Safety 
Engineer  evaluates  proposed  concepts  and 
architectures  to  identify  and  assess 

implications  of  energetic  materials, 

explosives,  hazardous  materials  and  provide 
recommendations  for  each  alternative.  The 
System  Safety  Engineer  assists  to  define  / 
refine  operational  and  system  safety  related  requirements  to  support  ICD  development  and  possibly  TRD 
development.  The  System  Safety  Engineer  also  contributes  to  the  development  of  the  MSA  Phase 
technical  products. 


MSA  Phase  -  Technical  Products  Required 


SMC  Safety  Technical 
Products 

Contributions  to  Other 
Organizations'  Products 

High  level  assessment  proposed 
concepts  &  architectures 

Operational  Concepts 

Safety  engineering  inputs  and 
factors  for  concept,  architecture, 
technology  studies,  and  trades 

AoA  Studies 

System  Safety  Req  ts  (draft) 

Initial  Capabilities  Doc  (ICD)  Dev 

Roadmap  and  architectural  inputs 
-  Identification  &  mitigations  of 
Safety  risks 

DoDAF  CVs,  OVs 
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TD  Phase  —  Technical  Products  Required 
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2 .  Technology  Development.  During  this 
phase  the  System  Safety  Engineer  continues 
to  provide  inputs  to  and  supports  the  JCEDS 
process.  The  System  Safety  Engineer  also 
supports  all  the  engineering  activities 
liiglilighted  within  the  box  titled 
Engineering  Activiti es  for  System  £  Segment 
Development  &  Design  Figure  15  to 
commence  system  definition  and 
development.  System  Safety  Engineer 


3.  Engineering  &  Manufacturing 
Development.  System  Safety  Engineer 
continues  to  provide  inputs  to  and  supports 
the  JCIDS  process.  The  System  Safety 
Engineer  supports  all  the  engineering 
activities  liiglilighted  within  the  box  titled 
Engineering  Activities  for  Detailed  Design 
Figure  15  to  commence  detailed  systems 
definition  and  development.  The  System 
Safety  Engineer  ensures  process  is  in  place 
to  report,  analyze,  and  mitigate  safety  / 
hazards  data  during  DT&E,  The  System 
Safety  Engineer  provides  inputs  to  and 
supports  the  JCEDS  process.  The  activities  of 
Safety  during  this  phase  are  extensive.  Refer  to  SMCI  63-1205.  SMC  Safety  Poiin\  doc  ess,  and 
Techniques  for  Safety  Engineer  activities  and  products  typically  required  during  each  phase.  The  System 
Safety  Engineer  develops  and  contributes  to  the  development  of  the  EMD  Phase  technical  products. 


SMC  Safety  Technical 

Pro  ducts 

Contributions  to  Other 
Organizations-  Products 

Inputs  to  System  Concepts 

Operational  Concepts 

Factors  for  Studies/  T rades 

Operational  Assessments 

Safety  Tech  Reqls,  TRD,  SRD, 
Specifications,  ICDs,  Standards 
Selection/  Tailor 

Capabilities  Development  Doc 
(CDD) 

Safety  inputs  to  ISP 

DoDAF  CVs,  OVs 

Prelim  hazards  list 

PESHE 

ID  Phase  technical  products. 

EMD  Phase  —  Technical  Products  Required 

SMC  Safety  Technical 

Pro  duets 

Contributions  to  Other 
Organizations/  Products 

Update  System  Concept 

Operational  Concepts 

Technical  Studies/  Trades 

Operational  Assessments 

System  Tech  Reqts,  TRD,  SRD, 
Spec,  ICDs;  Safety  requirements 
flow-down  /  allocations 

Capabilities  Production  Doc 
(CPD) 

Inputs  to  system  design, 
production,  fielding,  sustain  docs 

DoDAF  CVs,  OVs 

PESHE  Update 

Safety  inputs  to  ISP 

Safety  /  hazards  analyses/report 

Safety  evaluations  of  Tech 
Orders,  operations  manuals 

Test,  Demo  reports 

4. 


P&D  /  O&S  Phase  -  Technical  Products  Required 

SMC  Safety  Technical 
Products 

Con  nib  n  rions  to  Other 
Organizations*  Products 

Inputs  ted)  baseline  engineering 
changes 

Supports bifity  assessment  Rpt 
Contribution 

Analyses  of  failures  and  mishap 
incidents 

Operational  Assessments 

Contributions 

Hazards  analyses  Report. 

Transition  &  Fielding  Docs 

SSMP  &  PESHE  Update 

T&E  /  Demo,  Safety  Reports 

Safety  evaluations  of  Tech 
Orders,  operations  manuals 

Production  &  Deployment,  Operations  & 

Support.  The  System  Safety  Engineer 
continues  to  ensure  design  meets  the 
contractual  safety  requirements  and 
manufacturing,  build  and  integration 
activities  do  not  induce  additional  safety 
risks.  The  System  Safety  Engineer  ensures 
the  Safety  program  appropriately  addresses 
orbital  safety:  collision  avoidance,  directed 
energy,  eud-of-lile  safing.  and  space 
environments  per  AFSPC  Supplement  to  AFI  91-202.  Refer  to  SMCI  63-1205.  SMC  Safety  Polices 
Process,  and  Techniques  for  Safety  Engineer  activities  and  products  typically  required  duiing  tliis  phase. 


The  Safety  Engineer  develops  and  contributes  to  the  development  of  the  P&D  /  O&S  Phase  tedmical 
products. 
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System  Safety  Manager's  Contribution  to  Program  and  Project 
Management 

Each  SMC  program  defines  their  business  model  and  approach  structure  based  primarily  on  their  program 
objectives,  program  and  technical  challenges,  organizational  structure,  as  well  as  program  and  engineering 
planning  (SEP  plus  detailed  SSMP). 


The  System  Safety  Manager  (SSM)  develops  and  implements  the  SSMP  to  achieve  Program  Office  system 
safety  objectives  and  requirements.  The  pi  aiming  defines  the  system  safety  tasks  and  fiuictions  to  be  performed 
and  products  to  be  developed:  timing  of  tasks,  task  outputs,  resources  (skills,  tools,  equipment,  and  completion 
criteria).  The  SSM  plans  tasks  to  integrate  safety  activities  within  the  Program  Office,  between  Contractors  and 
government  stakeholders.  The  SSM  plans  the  tasks  to  establish  and  manage  hazards:  conduct  system  safety 
forums;  support  SE&I  activities,  risk  management,  integration,  and  system  modifications:  coordinate  the 
system  safety  planning  with  SMC  Staff  Safety  Office,  operating  commands,  supporting  commands,  and  test 
agencies;  integrate  system  safety  planning  with  other  functional  and  acquisition  plans  (i.e.  ASD,  RFP.  SEP. 
TEMP,  ASP,  LCMP). 


Execution  of  the  System  Safety  planning  is  typically  defined  hi  the  SSMP  which  implements  SMC  and  ldgher 
level  instructions,  policies,  arid  directives.  The  SSM  provides  fiiil  support  to  define  the  program  and  technical 
objectives  where  system  safety  challenges  and  risks  are  known  or  anticipated.  The  SSM  assists  to  establish  the 
business  model,  develop  program  planning  and  schedules,  and  define  and  implement  program  processes.  The 
SSM  ensures  the  system  safety  components  of  the  program  are  appropriately  represented  in  the  program  plans  * 
program  schedules,  work  breakdown  structures,  aud  cost  estimates.  The  SSM  also  reports  their  technical 
performance  and  progress.  The  SSM  shares  hi  the  risk  management  responsibilities  to  identify,  assess,  and 
propose  mitigating  actions  of  system  safety  related  risks.  The  SSM  also  support  the  program  manager's 
problem  identification,  resolution,  aud  decision-making  processes. 


The  SSM  contributes  to  the  development  of  the  program 
management  products  identified  in  the  Table. 


SMC  Program  Management  Products 


PMD 


ASD,  SSMP,  SEP.  PESHE,  TEMP,  HSIP,  ILSP 


Decision-making  &  problem  solving  inputs 


Technical  progression  and  issues  reporting 


LG  Cost  Estimate  (CARDs) 


Processes  (01s) 


Risk  Management  Inputs 


Program  Protection 
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Appendix  L  -  Acquisition  Systems  Protection  &  International 
Program  Security 

Program  protection  planning  is  integral  to  the  overall  acquisition  strategy  and  is  performed  at  the  front  end  of 
the  program.  The  program  identifies  Critical  Program  Information  (CPI)  for  the  acquisition  program  I  AW 
DoDI  5200.39,  AFPM  63-1701,  and  APPD  63-17.  CPI  applies  to  components,  engineering,  design, 
manufac hiring  processes,  or  technologies  that,  if  compromised,  could  cause  significant  degradation  in  mission 
effectiveness,  shorten  the  expected  combat-effective  life  of  the  system,  or  reduce  technological  advantage 
(DoDI  5200.39). 

The  Program  Protection  Engineer  (PPE)  identifies  the  resources  needed  to  accomplish  the  evaluation  and 
initiates  protection  if  required,  at  the  ear  best  possible. 

The  required  extent  of  program  protection  (PP)  strongly  depends  on  the  nature,  significance,  and  criticality  of 
CPI  identified  for  the  program  and  the  overall  DoD  mission.  If  no  CPI  is  identified,  only  a  program  letter 
stating  the  fact  is  required  which  is  then  approved  by  the  decision  authority. 

If  it  is  determined  that  the  program  contains  CPI,  a  program  protection  plan  (PPP)  is  required  during  the 
technology  development  phase  and  made  available  to  the  decision  authority  at  Milestone  B.  For  cooperative 
programs  with  foreign  participation,  a  technology  assessment  and  control  plan  (TA/CP)  is  required  LAW  DoDI 
5200.39,  DoD  5220. 22M,  DoDD  5530.3,  and  DoDI  S -52 3 0.28,  as  an  annex  to  the  PPP.  Furthermore,  a 
Delegation  of  Disclosure  Authority  Letter  (DDL)  IAW  DoDD  5230.11,  enclosure  d,  is  also  produced  as  ail 
aimexure  to  the  PPP. 

Depending  on  the  nature  aud  significance  of  the  CPI  other  docnments.  usually  annexed  to  the  PPP.  are  required 
that  include  (i)  Counterintelligence  (Cl)  support  plan,  (ii)  System  Security  Management  Plan  (SSMP)  IAW 
M3L-HDBK- 1785,  (in)  Security  Classification  Guide  (SCO)  LAW  DoD  5200. 1-R  and  DoD  5200. 1-H,  (iv) 
OPSEC  plan  LAW  DoDD  5205.02  and  DoDD  5205. 02 -M,  aud  (v)  classified  anti-temper  (AT)  plan. 

Tills  section  on  program  protection  engineering  should  be  read  in  conjunction  with  the  sections  on  Information 
Assurance  (LA)  and  Net-centric  Engineering  (NCE)  SEDs. 

Applicable  governance,  standards,  and  guidance 

Table  17  identifies  the  significant  governance,  standards,  and  guidance  winch  generally  require  SMC 
compliance  for  program  protection  engineering. 

Table  17  Governance,  standards,  and  guidance  that  sliape  the  Program  Protection  Engine eiiug  discipline 


Document  No 

Governance  Title 

Issue 

DoDD  5000.01 

Defense  Acquisition  System,  El.  1.9.  Information  Assurance 

20  Nov  07 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System,  "Title  40/Qinger  Chen 

Act  (CCA)"  Compliance 

08  Dec  08 

DoDM52Q0.39  Change  1 

Critical  Program  Information  (CPI)  Protection  Within  the  Department 
of  Defense 

28  Dec  10 

DoD  5200.1-Rand  DoD 
5200.1-H.  Change  1 

DoD  Information  Secunty  Program  and  Protection  of  Sensitive 
Compartmented  Information 

13 Jun  11 
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DoDD  5205.02  and 

OoDD  5205.02-M 

DoD  Operations  Security  (GPSEC)  Program  Manual 

03  Nov  08 

DoDD  5530.3  Change  1 

International  Agreements;  Enclosure  7  Technology 

Assessment/Control  Plan  (TA/CP)  International  Agreements 

18  Feb  91 

DoDI  S-5230  28 

Technology  Assessment/Control  Policy  on  export  restrictions  (?) 

26  May  05 

OoDD  5230.11 

Disclosure  of  Classified  Military  Information  to  Foreign  Governments 
and  International  Organizations:  Enclosure  4  Delegation  of 

Disclosure  Authority  Letter  (DDL)  on  foreign  collaboration 

16  Jun  92 

MIL-HDBK-1785 

System  Security  Program  Management  Requirements 

01  Aug  95 

AFPM  63-1701 

Program  Protection  Planning 

27  Mar  03 

AFPD  63-17 

Technology  and  Acquisition  Systems  Security  Program  Protection 

02  Apr  07 

Document  No 

Standards  Title 

Issue 

|  AFPM  63-1701  | 

Program  Protection  Planning  (PPP) 

27  Mar  03  | 

Document  No 

Guidance  Title 

Issue 

- 

DASD  for  Cyber ,  Identity,  and  Information  Assurance  Strategy 

Aug  09 

Defense  Acquisition 
Guidebook  (DAG) 

DAG,  Chapter  8;  Intelligence,  Counterintelligence,  and  Security 

Support,  Section  8.4  Acquisition  Protection  Strategy  for  Program 
Managers 

Current  at 
https://diag.dau.mil/ 

PPE's  Contributions  to  the  Acquisition  Life  Cycle  Framework 

Effective  program  protection  planning  begins  by  the  appointed  PPE  reviewing  the  acquisition  program  to 
determine  if  it  contains  CPI.  If  there  is  no  CPI  associated  with  the  program  the  appropriate  authority  or 
acquisition  executive  is  informed  accordingly,  and  no  fluther  program  protection  documentation  is  required. 

If  review  identifies  CPI,  whether  new7  or  inherited  ffom  other  programs,  PPP  is  required.  The  document  is 
developed  dining  the  technology  development  phase  and  it  is  first  presented  to  the  milestone  decision  authority 
at  milestone  B.  It  is  updated  for  each  subsequent  milestone.  During  operations,  the  PPP  is  revised  and  updated 
once  every  three  years,  or  as  required  by  changes  to  acquisition  program  status  or  the  projected  tlireat. 

The  PPP  is  used  to  coordinate  and  integrate  all  protection  efforts  designed  to  deny  access  to  CPI  to  anyone  not 
authorized  or  not  having  a  need -to -know  and  prevent  inadvertent  disclosure  of  leading  edge  technology  to 
foreign  interests.  If  there  is  to  be  foreign  involvement  in  any  aspect  of  the  program,  or  foreign  access  to  the 
system  or  its  related  information,  the  PPP  contains  provisions  to  deny  inadvertent  or  unauthorized  access.  The 
PPE  and  liis  teclmology  protection  team  is  responsible  for  developing  and  implementing  PPP. 
Counterintelligence  (Cl)  and  security  support  activities  and  program  protection  staff  elements  also  assist  the 
PPE  in  identifying  CPI. 

After  the  protection  planning  foundation  is  laid,  the  program  proceeds  tluough  the  milestones  and  phases  of  the 
acquisition  process.  The  program  follows  an  event-based  schedule  that  implements  the  protection  strategy  and 
completes  the  actions  outlined  in  the  PPP. 

Figure  17  shows  the  PP  engineering  contributions  and  required  products  witlihi  the  phased  acquisition  lifecycle 
framework.  This  figure  delineates  the  Program  Office  PP  engineering  responsibilities  and  requirements  to 
perform  PP  planning,  support  pre-  and  post- contract  award  acquisition  activities,  and  performs  PP  engineering 
management  across  the  system  lifecycle,  consistent  with  the  tenets  of  appropriate  policies,  SMC  acquisition 
objectives,  and  overall  program  SE  objectives.  The  Program  Office  PPE  helps  develop,  attain  approval  for,  and 
implement  the  PPP  and  related  artifacts  that  may  include  Cl  support  plan.  Security  Classification  Guide  (SCG), 
OPSEC  plan. 


Program  Protection 
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Anti -Tamper  (AT)  plan,  and  TA  CP  to  comply  with  I&S  requirements  in  accordance  with  current  Do D  policy. 

SMC  Program  Offices  appoint  establish  and  implement  program  protection  strategies  and  objectives  consistent 

with  SMC  acquisition  objectives. 

The  following  paragraphs  provide  a  listing  of  activities  and  the  required  PP  engineering  products. 

1.  Mate  lie  1  Solution  Analysis,  During  this  phase,  the  SMC 
PM  or  equivalent  appoints  or  assumes  responsibilities  of 
the  PPE.  The  PPE  reviews  program  objectives, 
descriptions,  and  other  relevant  data  to  identify  CPI.  The  need  to  collaborate  or  share  CPI  with  foreign 
entities  is  also  established.  PPE  also  provides  inputs  to  the  overall  systems  engineering,  initial  capabilities 
document,  cost  estimates  for  program  protection,  solicitation  REP  development  for  contractor  studies,  and 
proposal  evaluation  activities  as  necessary. 

2.  Technology7  Development  For  MS  B,  PPE:  (i)  ensures 
PP  considerations  are  incorporated  in  the  progr  am  ASP, 

(ii)  updates  list  of  CPI,  (iii)  ascertains  collaboration  or 
sharing  of  CPI  with  foreign  or  commercial  interests  and 
develops  technology  assessment^  on  trol  plan  as 
necessary,  (iv)  performs  PP  risk  assessment  and  develops 
counterintelligence  support  plan  integral  to  the  overall  SE 
process,  (v)  secures  resources  for  PP  budget,  and  (vf)  supports  RFP  development  effort  to  ensure  adequate 
CPI  protection. 

3.  Engineering  &  Manufacturing  Dev  elopment,  For  MS 
C,  the  PPE  updates  the  PPP  including  its  foreign 
disclosures  annexes  and  security  classification  guide 
based  on  updated  risk  management  plan.  Cl  support  plan 
and  other  analyses  integral  to  the  overall  SE  process.  PPE 
supports  RFP  development  by  evaluating  and  mitigating  risk  in  contract  vehicles  that  may  result  in 
unfavorable  sharing  or  export  of  certain  technologies  and  CPI. 

4.  Production  &  Deployment,  Operations  &  Support, 

The  PPE  maintains  system's  PP  plan  throughout  its 
lifecycle.  It  includes  periodic  assessment  of  CPI,  review 
and  approval  foreign  disclosure  posture,  and  review7  and 
approval  of  PPP  by  the  MDA. 


P&D  /  O&S  Phase  -  SMC  Acquisition 
Products 


Update  PPP  at  deployment _ 

Update  PPP  every  3  years  during  operations 


EMD  Phase  -  SMC  Acquisition  Pro  ducts 


Update  PPP _ 

Update  Foreign  disclosures  as  necessary _ 

RFP:  PP  objectives  in  the  S00;  PP  related  tasks  in 
SOW,  PP  planning  data  products  rn  CDRLs; 


TD  Phase  —  SMC  Acquisition  Products 


Updates  to  list  of  CPI _ 

Military  Critical  Technology  List  citations  for  applicable 
CPI _ 

Foreign  disclosures  as  necessary _ 

Initial  PPP _ 

RFP:  PP  objectives  in  the  S00;  PP  related  tasks  in 
SOW,  PP  planning  data  products  in  CDRLs; 


MSA  Phase  —  SMC  Acquisition  Products 


Identification  and  list  of  CPI 
CPI  Section  in  ICO,  APB 
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Figure  17  Acquisition  life  cycle  process  for  SMC  Program  Protection  Engineering 
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PPE's  Contributions  to  the  Engineering  Life  Cycle  Framework 

Wlien  the  acquisition  program  contains  Critical  Program  Information  (CPI),  the  PPE  initiates  a  program 
protection  planning  process  that  includes:  (i)  identify  and  prioritize  CPI,  (ii)  Identify  the  foreign  collection 
threat  to  the  program,  (iii)  identify  specific  program  vulnerabilities  and  risk  (iv)  identify  Research  and 
Technology  Protection  (RIP)  counter  measures  to  reduce,  control,  or  eliminate  risk,  (v)  identify  AT  techniques 
and  system  security  engineering  (SSE)  measures  to  protect  CPI  and  integrate  these  techniques  with  the  overall 
SE  design,  (vi)  identify  and  document  classification  needs  in  Security  Classification  Guide,  (vii)  identify 
protection  costs  associated  with  personnel,  products,  services,  equipment,  contracts,  and  facilities,  (viii) 
identify  the  risks  and  benefits  of  developing,  producing,  or  selling  the  system  to  a  foreign  interest,  (ix)  identify 
contractual  actions  required  to  ensure  that  planned  SSE,  AT  techniques,  IA,  classification  management,  and/or 
RTP  countermeasures  are  appropriately  applied  by  defense  contractors,  and  (x)  coordinate  with  supporting 
programs  to  ensure  that  measures  taken  to  protect  CPI  are  maintained  at  an  equivalent  level  throughout  the 
DoD  and  its  supporting  contractors. 

The  details  in  PPP  are  limited  to  information  needed  to  protect  CPI  and  ail  executable  plan  to  implement 
associated  countermeasures  over  the  entire  lifecycle  of  the  acquisition.  While  there  is  no  specific  format  lor 
PPPs,  the  PPE  is  expected  to  develop  the  following  content: 

•  A  list  of  program  CPI: 

•  Counterintelligence  (Cl)  Analysis  of  CPI:  When  ail  acquisition  program  containing  CPI  is  initiated, 
the  Program  Manager  (PM)  should  request  a  Cl  Analysis  of  CPI  from  the  sen/icing  Cl  organization. 
The  Cl  Analysis  focuses  on  how  the  opposition  sees  the  program  and  on  how  to  counter  the 
opposition's  collection  efforts.  The  Cl  analyst,  in  addition  to  having  an  in-depth  understanding  and 
expertise  on  foreign  intelligence  collection  capabilities,  must  have  a  good  working  knowledge  of  the 
U.S.  program.  Therefore,  Cl  organizations  need  information  that  describes  the  CPI  and  its  projected 
use  to  determine  the  foreign  collection  threat  to  an  acquisition  program.  The  Cl  analytical  product  that 
results  from  the  analysis  will  provide  the  PM  with  an  evaluation  of  foreign  collection  threats  to 
specific  program  or  project  technologies,  the  impact  if  that  technology  is  compromised,  and  the 
identification  of  related  foreign  technologies  that  could  impact  program  or  project  success.  The  Cl 
analytical  product  is  updated  as  necessaiy  (usually  prior  to  each  major  milestone  decision)  throughout 
the  acquisition  process.  Changes  are  briefed  to  the  program  or  project  manager  within  60  days 

•  Yu  hier a  bilities  of  C  PI ; 

•  All  Research  and  Technology  Protection  (RTP)  countermeasures  (e.g.,  anti -tamper  techniques,  system 
security  engineering)  and  Military  Critical  Technology  List  citations  for  applicable  CPI: 

•  All  RTP  associated  costs,  by  Fiscal  Year,  to  include  PPP  development  and  execution: 
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•  Cl  Support  Plan  (CISP):  The  CISP  defines  specific  counterintelligence  (Cl)  support  to  be  provided  to 
the  research,  development,  test  and  evaluation  (RDT&E)  facility  or  acquisition  pro  gram  and  provides 
the  servicing  Cl  personnel  with  information  about  the  facility  or  program  being  supported.  A  tailored 
CISP  is  developed  for  every  DoD  RDT&E  activity  and  for  each  DoD  acquisition  program  with 
identified  Critical  Program  Information  (CPI);  RDT&E  site  d hectors,  security  managers,  and 
supporting  Cl  organizations  are  responsible  for  developing  a  CISP  for  each  RDT&E  facility:  Program 
managers  (PMs)  and  their  supporting  security  and  Cl  organizations  are  responsible  for  developing  a 
CISP  for  each  acquisition  program  with  CPI.  The  CPI  will  be  fisted  hi  the  CISP. 

•  Current  S  e  cmi  ty  C 1  a  ssific  a  tion  Guid  e : 

•  Foreign  disclosure,  direct  commercial  sales,  co -production,  hnpoit  export  license  or  other  export 
authorization  requirements,  and/or  Technology  Assessment/Control  Plan  (TA/CP)  IAW  DoDD 
5530.3  and  Intelligence  Community  Directive  (ICD)  301.  The  TA/CP  analysis  often  assists  in 
developing  vulnerabilities  and  proposed  RTP  countermeasures. 

•  Delegation  of  Disclosure  Authority  Letter:  The  program  manager  must  prepare  a  DDL  as  part  of  a 
recommendation  for  foreign  involvement,  disclosure  of  the  program  to  foreign  interests,  request  for 
authority  to  conclude  an  international  agreement,  or  a  decision  to  authorize  foreign  sales. 

•  Anti -Tamper  Plan:  Program  managers  develop  and  implement  anti -tamper  (AT)  measures  to  protect 
Critical  Program  Information  (CPI)  in  U.S.  defense  systems  developed  using  co -development 
agreements,  sold  to  foreign  governments,  or  no  longer  within  U.S.  control  (e.g.,  theft,  battlefield  loss). 
The  DoD  Anti-Tamper  Executive  Agent  (ATE A)  resides  with  die  Department  of  the  .Air  Force.  AT 
implementation  is  tested  and  verified  during  developmental  test  and  evaluation  and  operational  test 
and  evaluation.  PPE  develops  the  validation  plan  to  secure  necessaiy  funding  for  the  AT  V&V  on 
actual  or  representative  system  components.  The  V&V  plan  is  developed  to  support  Milestone  C,  is 
reviewed  and  approved  by  the  AAF  ATE  A,  and  validation  results  are  reported  to  die  Milestone 
Decision  Authority. 

•  System  Security  Management  Plan  (SSMP):  If  necessary,  the  PPE  helps  develop  the  SSMP  for  the 
program  to  hite grate  RTP  into  the  systems  engineering  process  LAW  MIL -HDBK- 1785. 

•  DoD  Information  Assurance  Certification  and  Accreditation  Process  (DIACAP)  certification:  All 
information  and  space  systems  must  comply  with  the  DIAC  AP  requirements  IAW  DoDD  8500.01. 

•  PPE  develops  the  Program  Security  Instruction,  if  appropriate. 

It  is  PPE's  responsibility  to  ensure  that  risk  associated  with  the  program  protection  is  seamlessly  integrated 
with  the  overall  SE  risk  management  effort.  Within  the  global  context  of  IA,  PPE  applies  risk  management 
process  to  identify,  evaluate,  rank,  and  control  loss  of  technology.  PPP  preparation  is  based  on  systematic  risk 
management,  not  risk  avoidance.  Costs  associated  with  protecting  CPI  are  balanced  between  protection  costs 
and  potential  impact  if  compromised.  The  program  accepts  residual  risk  with  approval  from  the  Milestone 
Decision  Authority.  The  PPP  is  classified  according  to  content. 
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Relationship  to  SE  Organization 


Program  Protection 


The  PPE  plans  and  executes  the  program  protection  engineering  and  management  efforts  in  an  integrated  and 
effective  manner  within  the  context  and  flail  support  of  the  overarching  Systems  Engineering  (SE)  function. 
PPE  ensures  that  each  progr  am  protection  SED  contribution  is  timely,  adequate,  consistent,  and  compliant.  The 
PPE  and  his  team  ensure  that  their  contributions  are  channeled  tl uough  the  Systems  Engineering  Analyses  and 
Control  activity. 

Progr  am  protection  (PP)  engineering  SED's  relationship  to  other  SEDs  is  summarized  hi  Figure  1.  As  shown  in 
Figure  1,  PP  engineering  solutions  for  the  program  strongly  interact  with  IA.  NCE.  and  test  SEDs. 

Relationship  to  other  SEDs 

Relationship  to  L4:  Within  the  global  context  of  IA,  PPE  applies  risk  management  process  to  identify, 
evaluate,  rank,  and  control  loss  of  technology.  It  is  PPE's  responsibility  to  remain  cognizant  of  the  program  I A 
effort  in  meeting  the  required  IA  controls  and  the  status  of  the  DIACAP  process  LAW  DoDI  8500.02. 

Relationship  to  NCE:  Program  protection  planning  has  become  significantly  more  complex  as  BoD  begins  to 
implement  Net-centric  Operations  and  Warfare  (NCOW)  doctrine  where  basic  premise  is  that  program  data  is 
developed  for  sharing  with  the  warfighter  in  near  real-time.  Tliis  is  contrary  to  the  legacy  view  where  access  to 
data  is  granted  with  stringent  item- by-item  qualification  process  and  controls  that  may  lead  to  loss  of 
timeliness  of  information.  It  is  PPE’s  responsibility  to  be  cognizant  of  the  computing  and  network  environment 
and  the  data  model  for  the  program.  Interoperable  environments  require  robust  and  pervasive  network  level  I A 
to  assure  Warfighter's  data  availability,  integrity,  and  confidentiality. 

Relationship  to  T&E:  As  part  of  the  PP  planning  and  implementation,  anti -tamper  are  identified, 
demonstrated,  and  verified.  V&V  activities  should  be  integrated  with  the  overall  test  and  evaluation  plan  for 
the  program. 


Tools  Selection  &  Use 

The  PPP  Engineer  considers  effectiveness  and 
efficiencies  gained  by  selecting  and  using  the 
best  choice  of  PPP  tools  considering  the  PPP  tool 
requirements  for  program  protection,  program 
security,  information  sharing,  automated  data 
exchanges  with  other  tools*  and  other 
considerations. 


PP  Functions  Requiring  Tools 


Technology  assessment  tools _ 

Trade  studies  and  analysis  of  PP/AT  technology  products 

Requirements  Analyses  &  Allocations _ 

System  Security  engineering  tools _ 

PP/AT  technology  V&V  and  Operational  testing 


Program  Protection 
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Engineering  Activities  and  Products  over  the  Life  Cycle 

Tlie  Acquisition  Program  Baseline  (APB)  includes  costs  related  to  PPP  implementation. 


1.  Materiel  Solution  Analysis.  During  this 
phase  the  PPE  provides  inputs  to  and 
supports  the  JCIDS  process.  Before  contract 
award,  PPE  helps  identify  CPI.  foreign 
involvement,  RTP  needs  and  costs,  AT  needs 
and  cost,  and  initiates  BIACAP  assessment. 


MSA  Phase  —  Technical  Products  Required 

SMC  PP  Technical  Products 

PP  Contributions  to 
Other  Organization! 

Identify  CPI 

PPP,  APB 

Identify  foreign  involvement 

DIACAP  Package 

Identify  RTP  needs  and  cost 

Identify  AT  techniques 

DIACAP  assessment 

2. 


Technology  Development.  During  this  phase 
the  PPE  continues  to  provide  inputs  to  and 
supports  the  JCIDS  process. 


TD  Phase  -  Technical  Products  Required 


3. 


Engineering  &  Manufacturing 
Develop  meet,)  PPE  continues  to  update  the 
PPP  and  provide  inputs  to  and  supports  the 
JCEDS  process. 


The  PPE  helps  develop  the  Anti -Tamper 
VScV  plan  for  review  and  approval  by  the 
DoD  .Anti-Tamper  Executive  Agent  (ATE A). 

At  Milestone  C,  validated  results  are  repotted  to  the  Milestone  Decision  Authority, 


SMC  PP  Technical  Products 

PP  Contnbndons  to 
Other  Organizations 

Update  CPI 

PPP,  APB 

Update  foreign  involvement 

DIACAP  Package 

Update  RTP  needs  and  cost 

Update  AT  techniques 

Cl  analysis  and  vulnerabilities 

Initiate  Cir  TA/CP,  AT  plans 

initiate  SCG,  SSMP 

DIACAP  assessment 

TD  Phase  -  Technical  Products  Required 

SMC  PP  Technical  Products 

PP  Conui  buttons  to 
Other  Organizations 

Update  CPI 

PPP,  APB 

Update  Cl,  TA/CP,  AT  plans 

PPP,  DIACAP  Package 

Update  SCG 

Update  SSMP 

AT  V&V  plan 

DIACAP  Package 

4. 


Production  &  Deployment,  Operations  & 
Support,  PPE  continues  to  provide  inputs  to 
and  supports  the  JCEDS  process. 


P&D  /  O&S  Phase  -  Technical  Products  Required 

SMC  PP  Technical  Products 

PP  Contributions  to  Other 
Organizations 

Periodic  CPI  reassessment 

PPP 

DIACAP  Package 

DIACAP  Package 

PPEs’  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  their  business  model  and  approach  based  primarily  on  program  objectives, 
technical  challenges,  organizational  structure,  and  required  engineering  planning  including  PP  for  cost- 
effective  execution. 
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After  completing  the  protection  planning  process,  the  PPE  assists  the  program  manager  in  implementation  of 
countermeasures  to  protect  the  CPI  at  each  location  and  activity  identified  in  the  protection  planning  process.  If 
appropriate,  PPE  helps  the  program  manager  to  outsource  PP  and  helps  develop  RFP/SOW  for  the  contract. 
That  contract  activity  may  include  initial  program  and  system  evaluation  as  well  as  program  protection 
planning  that  leads  to  specific  Research  and  Technology  Protection  countermeasures.  Early  planning  is 
necessary  to  ensure  that  funds  are  programmed  and  budgeted  to  provide  timely  required  contract  support. 

PPE  is  responsible  for  early  coordination  of  the  RTP  on  behalf  of  the  program  manager  and  the  contracting 
personnel  to  ensure  documents  contain  essential  protection  requirements.  The  expected  range  of  protection 
requirements  and  projected  resources  required  should  be  estimated  to  ensure  research  and  acquisition  planning 
documents  address  RTP. 


Survivability 
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Appendix  M  -  Survivability  Engineering 

A  sound  survivability  program  is  conducted  during  all  phases  of  acquisition  to  ensure  that  space  systems  can 
survive  and  operate  under  benign  and  hostile  battlefield  conditions  including  nuclear,  chemical,  biological, 
conventional,  blast  and  Augmentation,  radiological,  electromagnetic,  and  natural  environments.  Survivability 
also  enables  rapid  restoration  of  the  system,  subsystem,  component,  or  equipment  to  improve  sustainability  of 
the  war- fighting  operations.  Survivability  engineering  and  management,  accomplished  early  hi  the  acquisition 
phase,  influences  the  selection  of  the  preferred  concept,  technologies,  and  the  eventual  design  and  identifies 
additional  support  resources  required  to  maintain  system  readiness.  Both  manmade  and  natural  causes  must  be 
factored  into  suivivable  system  development,  design,  and  operation.  Hence,  the  SMC  Program  Office 
Survivability  Engineer  supports  the  full  range  of  concept  development,  requirements  development,  engineering 
analyses  and  trades,  system  design  and  system  survivability  verification  and  validation. 

The  Program  Office  survivability  program  also  pursues  survivability  related  technology  advancement 
leveraging  research  facilities,  organizations,  and  projects.  For  example,  the  survivability  program  leverages 
radiation-hard  electronics  tecluio  logics  and  industrial  base  information  through  the  DoD  Radiation  Hardened 
Oversight  Council  (RHOC)  as  well  as  commercial  sector  manufacturers,  government  labs,  and  other 
government  agencies.  Survivability  is  the  capability  of  a  system  to  operate  without  degraded  performance  if 
exposed  to  adverse  natural  and/or  hostile  environments.  System  survivability  extends  to  include  the  personnel 
and  their  interactions  essential  to  operate  the  system,  usually  relevant  to  ground  segments.  Survivability  and 
force  protection  KPPs  generally  apply  to  SMC  ground  systems  and  missions  that  rely  on  human  interaction  to 
protect  and  safeguard  the  warfighter.  System  survivability  is  also  extended  to  a  system's  supporting 
infrastructure  (facilities,  basing,  subsystems,  etc.)  and  other  interfacing  systems.  AFSPC  requires  all  new  space 
acquisitions  to  address  space  protection  requirements  (including  survivability)  as  KPPs  or  Key  System 
Attributes  (KSAs),  where  appropriate. 

These  requirements  are  to  be  based  on  system  specific  validated  tlueats  and  vulnerabilities.  Comprehensive 
analysis  of  tlireat,  impact  of  loss,  countermeasures,  and  cost  are  required  to  determine  how  the  KPPs  or  KSAs 
are  correlated  to  the  protection  of  the  space,  link,  ground  infrastructure,  or  cyber  system  components.  The 
Personnel  Survivability  and  Force  Protection  are  mandatory  Key  Performance  Parameters  (KPPs)  generally 
applicable  to  ground  systems.  JCIDS  Manual,  enclosure  B,  para  2a,  31  Jan  2011  update  states  “[survivability] 
includes  attributes  such  as  speed,  maneuverability,  detectability,  and  countermeasures  that  reduce  a  system's 
likelihood  of  being  engaged  by  hostile  fire,  as  well  as  attributes  such  as  armor  and  redundancy  of  critical 
components  that  reduce  the  system's  vulnerability  if  it  is  hit  by  hostile  fire.”  This  aspect  of  survivability  is 
addressed  by  hi  the  HSI  SED. 

Tills  SED  describes  essential  tasks  and  products,  based  oil  current  mandates,  policy,  and  practices,  for  the 
Survivability  Engineer.  The  Program  Office  Survivability  Engineer  plans  and  performs  the  essential 
engineering  and  management  efforts  to  ensure  that  the  resulting  survivability  contributions  are  timely, 
adequate,  consistent,  and  compliant  with  the  military  need. 
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Applicable  governance,  standards,  and  guidance 

Table  18  below  identifies  the  significant  governance,  standards,  and  guidance,  which  generally  requires  SMC 
compliance  for  Survivability. 

CJCSI3H0.01  requires  consideration  of  survivability  as  a  part  of  the  operational  effectiveness  that  need  to  be 
incorporated  hi  the  CDD,  CPE),  or  OR D  addressing  Survivability  KPPs.  DODD  5000.01  requires  that 
acquisition  of  systems  apply  a  total  systems  approach  to  optimize  system  performance,  operational 
effectiveness,  suitability,  survivability,  safety,  and  affordability.  DODI  5000.02  requires  systems  and  personnel 
survivability  compliance  with  chemical,  biological,  radiological,  and  nuclear  survivability  requirements  at 
Milestones  B  and  C.  5000,02  also  instructs  that  the  Program  Manager  or  Ills  designee  {Survivability  Engineer) 
address  personnel  survivability  issues  including  protection  against  fratricide,  detection,  and  instantaneous, 
cumulative,  and  residual  nuclear,  biological,  and  chemical  effects:  personnel  survivability  against  asynunetric 
threats.  The  PM  is  required  to  address  special  equipment  or  gear  needed  to  sustain  crew  operations  hi  the 
operational  environment,  including  the  suitability  of  equipment  intended  to  enhance  personnel  survivability 
against  asynunetric  threats. 

DoDI  3222.3  stands  up  a  DoD  level  Electromagnetic  Environmental  Effects  (E3)  program  to  develop  a 
survivability  criteria.  DODI  3150.09  and  DODD  S -52 10. 81  require  SMC  programs  to  address  chemical, 
biological,  radiological,  nuclear  (CBRN)  survivability  for  SVs,  usually  as  a  KPP  or  KSA  (JCIDS  Manual,  Jan 
31,  2011,  Appendix  A.  Enclosure  H).  AFI  63-101  defines  system  survivability  and  sets  up  roles  and 
responsibilities  to  meet  mandated  requirements  to  include  implementation  of  a  hardness  assurance, 
maintenance,  and  surveillance  (HAMS)  program  IAW  DNA-H-93-140.  Military  Handbook  for  Hardness 
Assurance.  Maintenance,  and  Surveillance  (HAMS). 

SMC  standard.  SMC-S-014,  provides  SMC  requirements  tor  contractor  performance  hi  defense  system 
acquisitions  and  teclmology  developments  for  survivability  program  management  for  space. 


Table  18  Governance,  standards,  and  guidance  that  shape  the  Survivability  Engineering  discipline 


Document  No 

Governance  Title 

Issue 

Public  Law  108-375  Sec 
141 

Development  of  Deployable  Systems  to  Include  Consideration  of  Force 
Protection  in  Asymmetric  Threat  Environment 

28  Oct  04 

Public  Law  108-375  Sec 
1053 

Survivability  of  Critical  Systems  Exposed  to  Chemical  and  Biological 
Contamination 

28  Oct  04 

50  USC  Section  1522 

Conduct  of  Chemical  and  Biological  Defense  Program  fCBDP) 

CJCSI 3170 

Joint  Capabilities  Integration  and  Development  System 

01  Mar  09 

OoDD  5000.01 

Defense  Acquisition  System 

20  Nov  07 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

DoDD  3222.3 

DOD  Electromagnetic  Environmental  Effects  (E3)  Program 

DoDI  3150.09 

The  Chemical,  Biological,  Radiological,  Nuclear  (CBRN)  Survivability 

Policy" 

17  Sep  08 

DoDD  S-5210  81 

United  States  Nuclear  Weapons  Command  and  Control,  Safety,  and 
Security 

1 8  Aug  05 

Stratcom  Instr  534-18 

Space  Survivability  Levels  (SSL)  Classified  SECRET/NOFORN 

AFI  63-101 

Acquisition  and  Sustainment  Life  Cycle  Management 

22  Mar  11 

AFSPCI62-201 

Hardness  maint/hardness  surveillance  prog  for  Survivability  of  AFSC 
Systems 

02  Feb  98 

Survivability 
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Document  No 

Standards  Title 

Issue 

MIL-STD461F 

Electromagnetic  Emissions  and  Susceptibility,  Requirements  for  the 

Control  of  Electromagnetic  Interference 

10  Dec  07 

SMC-S-008 

Electromagnetic  Compatibility  Requirements  For  Space  Equipment  And 
Systems 

13  June  08 

SMC-S-009 

Parts  Materials  and  Processes  Control  Program 

12  Jan  09 

SMC-S-010 

Technical  Requirements  for  Electronic  Parts,  Materials,  and  Processes 

For  Space  and  Launch  Vehicles 

12  Jan  09 

SMC-S-014 

Survivability  Program  Management  for  Space 

19  July  10 

Document  No 

Guidance  Title 

Issue 

MIL-HDBK-1799 

Survivability  Aeronautical  Systems 

14  Feb  97 

JCIDS  Manual 

Manual  for  the  Operation  of  the  Joint  Capabilities  Integ  and  Development 
System 

31  Jan  11 

MIL-HDBK-237D 

Electromagnetic  Environ  Effects  &  Spectrum  Mgt  Guidance  for  Acquisition 
Process 

20  May  05 

HDBK  DNA-H-93-140 

Military  Handbook  for  Hardness  Assurance,  Maintenance,  and 

Surveillance  (HAMS) 

01  Feb  95 

MIL-HDBK-279 

Total  Dose  Hardness  Assurance  Guidelines  for  Semiconductor  Devices 
and  Microcircuits 

24  JAN  89 

M1L-HDBK-423 

High-Altitude  Electromagnetic  Pulse  (HEMP)  Protection  for  Fixed  and 
Transportable  Ground-Based  Facilities,  volume  1,  Fixed  Facilities 

15  May  93 

MIL-FIDBK-814 

Ionizing  Dose  and  Neutron  Hardness  Assurance  Guidelines  for 

Microcircuits  and  Semiconductor  Devices 

08  Feb  94 

M1L-HDBK-815 

Dose  Rate  Elardness  Assurance  Guidelines  7  Nov  94,  Notice  1 10  Jan 

2002,  and  Notice  2 

13  Nov  06 

MIL-HDBK-816 

Guidelines  for  Developing  Radiation  Hardness  Assurance  Device 
Specifications,  9  Sep  94  Note  1, 8  Apr  2002,  Note  2 

11  Apr  07 

M1L-STD-1 899 

Space  Environment  for  USAF  Space  Vehicles 

15  Feb  91 

MIL  STD  188-125  -1 

High  Altitude  Electromagnetic  Pulse  (HEMP)  Protection  for  Ground  Based 
C4I  Facilities  Performing  Critical  Time-Urgent  Mission,  Fart  1:  Fixed 
Facilities 

17  Ju!  98 

MIL  STD  188-125-2 

High  Altitude  Electromagnetic  Pulse  (HEMP)  Protection  for  Ground  Based 
C4I  Facilities  Performing  Critical  Time-Urgent  Mission,  volume  1 : 
Transportable  Facilities 

03  Mar  99 

DTRA-TR-GO-39  V2 

Radiation  Effects  Testing  Handbook, 

01  Aug  01 

Survivability  Engineers'  Contributions  to  Acquisition  Life  Cycle 
Framework 

1.  Materiel  Solution  Analysis*  The  Survivability  Engineer 
establishes  the  need  and  extent  of  the  chemical, 
biological,  radio  logic  al:  and  nuclear  (CRBN) 

survivability  analyses  required  to  meet  the  relevant  KPPs 
and  program  KSVs  I  AW  with  the  JCIDS  manual  and  the 
references  cited  therein.  The  Survivability  Engineer  also  assesses  impact  of  E3  effects  and  in-orbit  space 
junk  and  particulates  that  may  adversely  affect  the  system  performance.  The  results  are  documented  in  the 
ICD  and  other  program  documents.  The  Survivability  Engineer  also  supports  the  operational  and  system 
survivability  concept  development  efforts  and  System  Threat  Analysis  Report  (STAR)  for  the  program. 
The  Survivability  Engineer  supports  NASIC  and  SMC/IN  in  STAR  development  by  evaluating  expected 
threats  and  vulnerabilities  at  the  ear  best  possible  phase  of  acquisition,  using  a  cost-effective  combination 
of  analysis,  model  big  and  simulation,  and  testing.  The  Survivability  Engineer  also  derives  and  manages 


MSA  Phase  —  SMC  Acquisition  Products 


Initial  CRBN  and  E3  analyses _ 

Inputs  to  ECD,  ASPr  STAR _ 

Inputs  to  5EFr  TEMP,  LCMP,  CARD, _ 

Inputs  to  concept  and  technology  studies,  trades 
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the  system  and  allocated  levels  of  Space  Situational  Awareness  (SSA)  requirements  to  detect,  characterize 
geo-locate,  and  report  survivability  threats  against  the  system.  The  Survivability  Engineer  also  maintains 
the  overall  security  of  the  survivability  strategy  of  the  program,  contributes  to  the  development  of  the 
program's  security  classification  guide,  and  reviews  all  of  the  contractors  and  sub  contractor's  security 
plans  to  make  sure  the  program  vulnerabilities  are  adequately  protected. 

For  SMC  space  programs,  a  special  emphasis  is  placed  on  nuclear  and  EMP  survivability  of  the  SVs  I  AW 
DODI  3150.09  and  DODD  S-5210.B1.  Initial  requirements,  results,  and  shortcomings  are  reported  in  the 
ICD  and  the  ASP,  if  available.  Survivability  Engineer  also  provides  inputs  to  the  overall  Systems 
Engineering  activities  to  include  concept  and  architecture  development,  technologies  studies,  engineering 
analyses  and  trades,  cost  estimates  (CARD),  solicitation/ RFP  development  for  Contractor  studies,  and 
proposal  evaluation  activities  as  necessary. 

2*  Technology  Development*  For  MS  B,  the  Survivability 
Engineer  refines  the  survivability  analyses  and  develops 
specific  survivability  requirements  that  are  measureable 
and  testable.  CBRN  survivability  is  a  requirement  of  all 
CBRN  mission-critical  systems  regardless  of  Acquisition 
Category.  Most  SMC  programs  are  mission  critical,  and 
as  such,  the  MS  B  ASP  should  include  the  Program 
Office  development  plans  to  ensure  an  appropriate  level 
of  chemical,  biological,  radiological  and  nuclear 
survivability  at  Initial  Operational  Capability  (IOC).  The 
ASP  should  also  generally  describe  survivability  requirements,  if  any.  The  Survivability  Engineer  also 
performs  the  necessary  studies  aud  analyses  to  show  that  the  overall  system  concept  and  unfolding  design 
is  in  compliance  with  the  survivability  KPPs  and  develops  related  cost  estimates.  The  Survivability 
Engineer  documents  survivability  shortcomings  for  management  decisions.  The  results  are  recorded  in  the 
CDD  and  the  ASP  to  support  the  MS  B  decision.  The  Survivability  Engineer  manages  the  development  of 
survivability  techniques  such  as  shielding,  countermeasures,  space  situational  awareness,  and  operational 
procedures  to  protect  the  system  against  threats  as  defined  in  the  STAR.  Survivability  Engineer  also 
provides  inputs  to  the  overall  Systems  Engineering  activities  to  include  concept  and  architecture 
development,  technology  studies,  engineering  analyses  and  trades,  requirements  development,  cost 
estimates,  solicitation/' RFP  development  for  Contractor  studies,  and  proposal  evaluation  activities  as 
necessaiy. 


TD  Phase  —  SMC  Acquisition  Products 


Inputs  to  ASPh  TDSr  DMS _ 

Inputs  to  Cost  Model,  CARD  Development _ 

Inputs  to  CDD,  STAR _ 

Update  to  CRBN  analyses;  Analyses  demonstrating 
survivability  KPP  compliance _ 

Detailed  survivability  planning  -  SVPP,  Inputs  to  SEP, 
TEMP,  LCMP,  TEMP,  ISP _ 

RFP:  Survivability  concepts;  TRD/spec  reqts  & 
tailoring;  SOO  objectives;  Survivability  tasks  in  PWS, 
Survivability  data  req  ts  CDRLs  &  Tailored  DIDs 
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3.  Engineering  &  Manufacturing  Development.  Tlie 
Survivability  Engineer  ensures  CBRN  survivability 
requirements  are  implements  and  verified.  The 
Survivability  Engineer  assists  to  identify  any  special  test 
and  evaluation  requirements.  In  sir  oil.  the  Survivability 
Engineer  (i)  incorporates,  implements,  and  validates 
survivability  design  solutions  based  on  defined 
requirements  (ii)  ensures  that  the  necessary  survivability 
-related  technical  requirements  (1RD)  are  in  compliance, 
and  (ii i)  supports  solicitation'RPP  development  and 
proposal  evaluation  activities  to  ensure  appropriate  cost- 
effective  survivability  technologies  are  acquired  to  meet 
program  objectives.  The  results  are  recorded  in  the  Capability  Production  Document  (CPD)  and  the  ASP 
to  support  the  MSC  decision. 


EMD  Phase  -  SMC  Acquisition  Products 


inputs  to  ASP,  TDSr  DM5 _ 

Inputs  to  System  Cost  Model,  LC  Cost  Estimate 
Update  /  CARD  Development _ 

Inputs  to  CPD,  Updates  to  STAR _ 

Update  to  CRBN  analyses;  Analyses  demonstrating 
survivability  KPP  compliance _ 

Detailed  survivability  planning  -  SVPP;  Inputs  to  SEP, 
TEMP,  LCMF,  TEMP,  ISP _ 

RFP:  Survivability  concepts;  TRD/spec  requirements 
and  tailoring  Objectives  in  the  S00;  Survivability 
related  tasks  in  PWS,  Survivability  data  requirements 
products  in  CDRLs;  Data  Item  Description  -  tailored 


4. 


Production  &  Deployment,  Operations  &  Support. 
The  Survivability  Engineer  maintains  system’s 
survivability  posture-  tluoughout  its  lifecycle. 


P&D  /  O&S  Phase  -  SMC  Acquisition 
Products 


Updates  to  ASP,  TPS,  DMS _ 

CARD  update _ 

RFP:  Survivability  related  tasks  in  PWS,  Survivability 
data  requirements  products  in  CDRLs;  Data  item 
Description  -  tailored _ 

Final  Survivability  compliance  analyses _ 

Survivability  planning  inputs  to,  SEP,  LCMP,  TEMP 
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Survivability  Engineers1  Contributions  to  Engineering  Life  Cycle 
Framework 

Relationship  to  SE  Organization 

Tlie  Survivability  Engineer  plans  and  executes  essential  survivability  engineering  and  management  efforts  in 
an  integrated  and  effective  manner  witliin  the  context  and  fiiil  support  of  the  overarching  Systems  Engineering 
function.  The  Survivability  Engineer  ensures  that  each  survivability  contribution  is  timely,  adequate, 
consistent,  and  compliant.  The  Survivability  Engineer  ensures  that  their  contributions  are  channeled  through 
the  Systems  Engineering  Analyses  and  Control  activity. 

Systems  Engineers  manage  the  engineering  process  and  activities  depicted  in  Figure  3  while  the  Survivability 
Engineer  contributes  to  this  process  by  performing,  managing,  and  supporting  the  concept  development  effort 
through  the  use  of  modeling  and  simulation,  analyses:  concept/architectural/design  trades:  and  technology 
studies.  The  Survivability  Engineer  contributes  to  the  Systems  Engineering  process  and  supports  technical  and 
program  management  activities  by  supporting  decision  making.  The  Survivability  Engineer  contributes  to 
concept  and  architecture  development  and  analyses:  evaluation  of  survivability  Technology,  aud  design 
solutions:  modeling  and  simulation  efforts:  survivability  requir  ements  development:  survivability  analyses:  and 
verification  and  validation  activities.  The  Survivability  Engineer  ensures  survivability  technical  requirements 
and  information  are  current  and  commensurate  with  program  maturity  aud  is  appropriately  applied  through 
systematic  control,  collaboration,  and  sharing  across  the  organization  to  integrate  with  all  SE  engineering 
functions  through  the  system  lifecycle.  This  includes  implementation  of  mandated  survivability  KPPs  and 
CBRN  requirements,  as  appropriate  to  the  system. 

Relationship  to  other  SEDs 

Survivability  Engineer  works  closely  with  T&E  Engineer  as  survivability  testing  is  a  key  p ait  of  the  overall 
T&E  strategy,  which  is  designed  to  provide  information  on  risk  and  risk  mitigation  and  determines  whether 
systems  are  operationally  effective,  suitable,  and  survivable  for  the  intended  use.  Modeling  and  simulation 
(M&S)  techniques  are  applied,  as  appropriate,  in  support  of  surviv ability  acquisition  activities.  For  example, 
M&S  is  essential  to  determine  the  total  radiation  dose  that  a  spacecraft  is  exposed  to  in  a  particular  orbit  for 
both  the  natural  environment  and  possibly  the  maiunade  altered  environment  after  a  high  altitude  nuclear 
detonation  (HAND)  event.  After  the  exposure  characteristics  are  mider stood  additional  extensive  modeling  is 
required  to  determine  the  dose  that  radiation -sensitive  electronic  parts  actually  accumulate  when  protected  or 
shielded  by  the  various  parts  of  the  spacecraft.  Survivability- associated  M&S  is  used  as  tools  in  technology 
areas  to  support  conceptual  analysis,  technology  development,  acquisition,  testing,  fielding,  sustainment, 
operational  effectiveness,  training,  and  planned  product  improvement. 

Personnel  survivability  is  addressed  by  both  the  Survivability  Engineer  and  the  HSI.  Personnel  survivability  is 
particularly  applicable  to  the  SMC  Programs1  user  and  ground  control  segments,  and  is  closely  associated  with 
the  HSI  activities.  The  Survivability  Engineer  aud  HSI  collaborate  to  produce  designs  as  well  as  operations, 
and  sustainment  procedures  that  protect  against  known  threats  and  mitigate  risk  to  the  warfighter. 

The  Program  Protection  Planning  (PPP)  and  Information  Assurance  (LA)  specialties  develop  the  Critical 
Program  Information  (CPI)  that  traditionally  relates  to  protection  of  technology  for  warfighter  advantage  to 
include  Anti-Tamper  and  Anti- spoof  for  increased  availability  of  mission  critical  systems.  LA  provides  security 
of  data  at  rest  and  in  transport  and  helps  protect  against  cyber  attacks  including  denial  of  service.  Both  PPP  and 
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IA  are  critical  to  loug  term  aud  extended  survivability  and  availability  of  mission  critical  systems.  The 
Survivability  Engmeer  closely  coordinates  with  and  contributes  concepts,  analyses,  and  data  on  survivability 
with  these  disciplines. 

Survivability  of  systems  strongly  depends  on  the  appropriate  choice  of  parts,  materials,  and  processing  and 
collaborates  with  the  PMP  Engineer.  For  example,  radiation  hardening  is  necessary  for  all  paits  and  materials 
deployed  in  space.  The  Survivability  Engineer  contributes  to  the  PMP  Engineer  activities  by  providing 
survivability  analyses  and  testing  to  help  make  appropriate  choices.  For  further  discussion  see  SMC -S- 00  9  and 
SMC-S-010. 

Other  important  system  engineering  disciplines  to  which  Survivability  Engineer  contributes  include 
Architecture  Development.  Design  Engineering,  Reliability,  and  Maintainability.  For  ground  and  space 
systems,  architecture,  design,  r  eh  ability  aud  maintainability  are  key  contributors  to  a  cost-effective  strategy  lor 
survivability  at  every  stage  of  development. 

Tools  Selection  &  Use 

The  Survivability  Engineer  considers 
effectiveness  and  efficiencies  gamed  by  selecting 
and  using  the  best  choice  of  survivability 
designs,  strategies  and  mitigation  technology  to 
meet  mission  critical  requirements,  including 
survivability  KPPs. 

Engineering  Activities  and  Products  over  the  Life  Cycle 

The  following  subsections  delineate  Survivability  Engineer  contributions  to  engineering  activities  and 
technical  products  by  DOD  acquisition  phase. 

1.  Materiel  Solution  Analysis*  Specifically, 
the  Survivability  Engineer  provides  inputs  to 
and  supports  (i)  Breakdown  of  system 
components  to  determine  the  critical 
segment  that  need  to  survive  to  be  able  to 
meet  the  overall  mission  KPP  requirements, 
identification  of  mission  criticality  of 
program,  (ii)  survivability  analyses,  (iii) 
survivability  threat  assessment,  (ivj  define 

the  testing  process  to  verify  survivability  KPP  compliance,  and  (v)  CRBN  requirements. 


MSA  Phase  -  Technical  Products  Requit  ed 


SMC  Survivability 
Technical  Products 

Contributions  to  Other 
Organizations*  Products 

Initial  CRBN  analyses/ 
requirements  for  analysis 

Inputs  to  CBA,  1CD;  threat 
assessments 

Architecture  inputs  and 
survivability  factors  for  concept, 
architecture,  technology  studies, 
and  trades;  CVsf  OVs 

Inputs  to  AoA  Studies; 

Technology  Roadmap 

Inputs  to  enabling  concepts 

Inputs  to  operational  concepts 

Survivability  Functious  Requiring  Tools 


Architecture  and  design  modeling;  Modeling  and  simulation  tools 

Trade  studies  and  analysis  of  survivability  technology,  techniques,  and 
designs _ 

Requirements  Analyses  &  Allocations _ 

Survivability  V&V 
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2.  Technology  Development.  The 
Survivability  Engineer  continues  to  provide 
inputs  and  supports  the  JCIDS  process.  The 
Siuvivability  Engineer  also  supports  all 
engineering  activities  to  update  and  refine 
survivability  analyses  and  requirements 
described  within  the  MSA  phase. 

The  Survivability  Engineer  also  supports  the 
concept  and  technology  development 
activities  highlighted  witliin  the  box  titled 
Engineering  Activities  for  System  Sc  Segment  Development  Sc  Design  Figure  18  to  commence  system 
definition  and  development.  The  Siuvivability  Engineer  contributes  to  development  of  technology 
roadmaps,  avoiding  use  of  high  risk,  immature  teclmologies  that  potentially  impact  system  survivability, 
and  system  trades  and  analyses. 

The  Siuvivability"  Engineer  performs  threat  assessments  or  assesses  the  adequacy  of  the  assessments  for 
each  design  concept  to  identify,  analyze  threats,  viable  solutions  and  determine  design  margin.  The 
Survivability  Engineer  ensures  the  Contractor  STAR  is  compatible  with  the  Government  STAR.  The 
Survivability  Engineer  ensures  hardness  analyses  are  performed  and  adequate  to  determine  hardness 
requirements,  hardness  allocations,  and  hardness  design  margins.  Survivability  Engineer  considers 
hardness  surveillance  and  maintenance  for  ground  systems.  As  applicable,  the  Survivability  Engineer 
plans  and  implements  a  hardness  assurance,  maintenance,  and  surveillance  (HAMS)  program. 
Survivability  Engineer  also  ensures  Contractor  the  Survivability  and  Vulnerability  Program  Plan  (SVPP) 
adequately  documents  survivability  engineering  management  and  teclmical  approaches  essential  for  the 
cost-effective  development  of  a  smvivable  system. 

The  Survivability  Engineer  contributes  to  the  development  of  TD  Phase  technical  products  with  emphasis 
on  enabling  and  critical  technologies.  The  Survivability  Engineer  also  provides  inputs  to  the  RFP.  PWS, 
TDS,  SEP,  and  CARD  that  includes  (i)  derivations  and  allocations  of  the  KPP/KSA  requirements  to  the 
TRD/  specification,  (ii)  teclmical  considerations  for  choosing  survivable  design  characteristics  and 
solutions,  (in)  solution  implementation  schedule,  (iv)  cost,  (v)  funding  profile,  and  (vi)  staffing  and 
support  requirements. 

3.  Engineering  &  Manilla  e  tilling 

Development.  The  Survivability  Engineer 
continues  to  provide  inputs  to  and  supports 
the  JCIDS  process.  The  Survivability 
Engineer  (i)  supports  engineering  activities 
to  further  develop,  refine,  or  modify  the 
survivability  solutions  of  the  system 
architecture  and  system  requirements,  (ii) 
ensures  the  siuvivability  solutions  are 
compliant  with  survivability  KPPs,  (iii)  supports  studies,  trades  and  decision  processes,  (iv)  refines  CRBN 
technical  requirements,  analyses  and  provides  proposed  solutions,  (v)  supports  development  of  IA/IA- 
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enabled  products,  (v)  helps  detemiine  and  implement  survivability  technology  insertion  and  solutions,  (vi) 
assists  to  arrange  and  schedule  specialized  testing  facilities,  (vii)  supports  RTF  development  and  source 
selection  activities,  and  (viii)  continues  to  support  technical  solutions  trades  to  ensure  compliance  with 
survivability  mandates  (KPPs.  CBRN).  The  Siuvivability  Engineer  also  works  closely  with  the  SEs  and 
other  specialty  engineers  in  performing  interface  analyses,  functional  analyses,  and  the  integration  and 
verification  and  validation  planning  and  execution,  and  conducts  survivability  training.  The  Survivability 
Engineer  ensures  adequacy  of  hardness  assurance  characterization  testing  (development)  and  lot 
acceptance  testing  (production). 

4.  Production  <&  Deployment,  Operations  & 

Support*  Survivability  Engineer  continues 
to  provide  inputs  to  and  suppoits  the  JCIDS 
process.  During  the  production  phase,  the 
Survivability  Engineer  helps  ensure  the  parts 
produced  are  adequately  hardened.  Hie 
Survivability  Engineer  reviews  and  approves  the  contractor's  survivability-related  test  procedures  and 
verifies  tliat  they  are  hi  compliance  with  the  test  plans  and  the  design  specifications.  Following  each 
survivability-related  test,  the  Survivability  Engineer  verifies  that  the  test  results  and  test  report  show7  that 
the  system  adequately  met  the  survivability  requirements.  Survivability  Engineer  continues  to  review 
revisions  of  STAR  and  intelligence  rep  oils  of  new?  threats  for  possible  impact  to  the  system.  If  on-orbit 
operational  anomalies  occur,  the  Survivability  Engineer  reviews  the  impact  of  the  anomalies  for  potential 
new  vulnerabilities  and  evaluates  strategies  to  mitigate  those  threats,  and  if  actual  attacks  are  made  against 
the  system,  the  impact  of  the  tin  eats  against  the  existing  design  needs  to  be  determined  and  design  changes 
evaluated  to  reduce  the  risk  to  the  mission  due  to  those  tlneats. 


P&D  /  O&S  Phase  -  Technical  Products  Required 


SMC  Siuvivability 
Technical  Products 

Contributions  to  Other 
Organizations'  Products 

Periodic  re-assessment  of 
system  survivability 

Supportabifity  Analyses  Rpt 

Inputs  tech  baseline  eng  changes 

Inputs  to  Transition  &  Field  Docs 

Survivability  Engineer  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  their  business  model  and  approach  based  primarily  on  program  objectives, 
technical  challenges,  organizational  structure,  and  required  engine eiing  planning  including  survivability  for 
cost-effective  execution. 

The  Survivability  Engineer  helps  the  Program  Manager  to 
fully  integrate  resources  and  skills  tliat  lead  toward  the 
intended  system  siuvivability  against  all  anticipated  tlneats  at 
all  levels  of  conflict  early  hi  the  program,  usually  before 
entering  production.  Siuvivability  Engineer  ensures  that 
M&S.  T&E,  and  HSI  and  other  specialty  engineers  are 


SMC  Program  Management  Products 


asp,  ien  con  cpn  star 


Decision-making  &  problem  solving  inputs 


Cost  Estimate  (CARDs) 


PWSt  RFP  ,  3RD,  TRD,  Source  Selection 


Developmental  and  Operational  tests 


Threat  Assessment  and  Risk  Management  Inputs 


involved  hi  the  decision  making  process  to  implement  survivability  mandates  to  mitigate  risk  to  the  warfighter 
and  system. 


The  Survivability  Engineer  further  assists  the  Program  Manager  to  ensure  CBRN  survivability  for  all  mission 
critical  systems  IAW  DoDI  3150.09,  whose  operating  environment  would  include  operating  hi  a  CBRN 
environment  according  to  STAR  or  Capstone  Threat  Document.  Cost-effective  survivability  techniques  and  a 
plan  for  the  v  alidation  and  confirmation  of  CBRN  survivability  should  be  developed. 
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The  Survivability  Engineer  manages  the  survivability  program  throughout  the  system  life  cycle  to  attain 
overall  program  objectives,  stressing  early  investment  to  provide  a  balanced  survivability  approach  that 
balancing  overall  survivability  requirements  with  other  design  characteristics  and  program  cost,  schedule  and 
performance  requirements  enhancing  mission  effectiveness  and  operational  readiness  requirements  by: 

•  Incorporating  design  features  to  prevent  or  reduce  engagement  of  threat  weapons 

•  Providing  mission  plaunhig  and  dynamic  situational  awareness  features  to  enable  tactical  threat 
avoidance 

•  Incorporating  vulnerability  reduction  features  including  design  redundancy 

The  Survivability  Engineer  verifies  that  the  performance  work  statement  (PWS)  and  teclmical  requirements 
document  (TRD)  in  the  REP  accurately  reflect  the  requirements  in  the  CDD,  and  that  the  survivability-related 
requirements  in  sections  L  and  M  will  allow7  the  Government  to  adequately  evaluate  the  contractor’s  capability 
to  meet  those  survivability  requirements.  During  the  a  dual  source  selections  or  down -selects,  the  Survivability 
Engineer  will  evaluate  the  contractor's  proposals  and  make  die  necessary  recommendations  to  the  Source 
Selection  Evaluation  Board  (SSEB)  and  Space  Situational  Awareness  (SSA)  concerning  the  adequacy  of  the 
contractor's  proposed  approach  to  meet  smvivability  requirements. 

The  Survivability  Engineer  develops  and  implements  the  smvivability  program  planning  to  achieve  the 
required  objectives  and  requirements.  The  planning  defines  the  survivability  related  tasks  and  functions  to  be 
performed:  products  to  be  developed;  and  timing  of  tasks,  task  outputs,  resources  (skills,  tools,  equipment,  and 
completion  criteria).  The  Survivability  Engineer  plans  tasks  to  integrate  survivability  activities  within  the 
Progiam  Office,  between  contractors,  and  community  stakeholders.  The  Survivability  Engineer  plans  the  tasks 
to  establish  and  manage  survivability  activities,  support  SE&I  activities,  e.g.,  system  technical  solutions  trades 
and  analyses  risk  management,  integration,  and  system  modifications;  coordinate  the  survivability  planning 
with  Systems  Engineering,  operating  commands,  supporting  commands,  and  test  agencies;  and  integrate  the 
planning  with  other  fimctional  and  acquisition  plans  (i.e.  SEP,  ASP,  LCMP). 

Execution  of  the  survivability  plamimg  is  typically  defined  through  an  Operating  Instruction  (OI).  The 
Survivability  Engineer  provides  full  support  to  define  the  progiam  and  technical  objectives  where  concept  and 
architectural  challenges  and  risks  are  known  or  anticipated.  The  Survivability  Engineer  ensures  the  concept 
development  and  management  components  of  the  program  are  appropriately  represented  in  the  program  plans, 
program  schedules,  w-ork  breakdown  schedules,  and  cost  estimates.  The  Survivability  Engineer  reports  their 
technical  performance  and  progress.  The  Survivability  Engineer  shares  in  the  risk  management  responsibilities 
to  identify,  assess,  and  propose  mitigating  actions  of  their  related  risks.  Survivability  Engineer  also  supports 
the  Program  Manager's  problem  identification,  resolution,  and  decision-making  processes. 
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Appendix  N  -  Human  Systems  Integration 

Within  the  Department  of  Defense's  acquisition  lifecycle  framework,  systems  engineering  and  program 
management  activities.  Human  Systems  Integration  (HSI)  is  a  vital  component  hi  the  DoD's  total  system 
approach. 

Human  Factors  Engineering  (HFE)  is  the  engineering  application  of  the  knowledge  of  human  capabilities  and 
limitations  with  respect  to  system  or  equipment  design,  development,  operations,  and  sustainment.  Its 
objective  is  to  maximize  efficiencies,  effectiveness,  and  safe  system  performance,  while  minimizing  cost, 
manpower,  skills  and  training  resources.  HSI  is  a  comprehensive  management  and  technical  strategy  to  ensure 
human  performance  factors  are  continuously  addressed  throughout  the  system  life  cycle. 

When  human  systems  integration  is  a  significant  factor,  the  SMC  program  office  establishes  and  designates 
authority  responsible  for  managing  and  executing  the  HSI  program.  Its  responsibilities  include  planning, 
supervising  and  ensuring  essential  HSI  and  management  efforts  are  integrated  with  the  various  acquisitions, 
management.  Sc  engineering  processes.  It  ensures  effectiveness  and  compliancy  to  the  assorted  policies.  DoD 
mandates,  instructions,  and  SMC  acquisition  program  and  technical  objectives,  as  it  pertains  to  the 
implementation  of  HSI  program  strategies  and  plans. 

Applicable  governance,  standards,  and  guidance 

HSI  is  an  integral  part  of  numerous  mandates  including  public  law,  policies,  directives,  and  instructions.  It  is  a 
Systems  Engineering  Discipline  (SED)  that  is  associated  with  multiple  functional  disciplines  witlrni  the 
Systems  Engineering  realm  including  acquisition,  information  assurance,  systems  engineering,  software 
engineering,  test  and  evaluation  and  others.  Table  19  below  identifies  the  significant  governance  which 
generally  requires  SMC  compliance  for  HSI. 


Table  19  Governs  nee,  standards,  and  guidance  that  sliape  tlie  Human  Systems  Integration  discipline 


Document  No 

Governance  Title 

Issue 

Public  Law  It 0-1 81, 

Section  231 

National  Defense  Authorization  Act  (NDAA)  2QG8F  OSD  HSI  Management 

Plan 

28  Jan  08 

DoDD  1100.4 

Guidance  for  Manpower  Management 

12  Feb  05 

DoDD  1322.18 

Military  Training 

13  Jan  09 

DoDD  5000.01 

The  Defense  Acquisition  System 

12  May  03 

DoD1 1100.22 

Policy  and  Procedures  for  Determining  Workforce  Mix 

12  Apr  10 

DoD1 1322.20 

Development  and  Management  of  Interactive  Courseware  (ICW)  for  Military 
Training 

14  Mar  91 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

DoDI  6055.1 

DoD  Safety  and  Occupational  Health  (SOH)  Program 

19  Aug  98 

FY09  DoD  Human  Systems  Integration  Management  Pan  Version  1 .0 

09 

CJCSI 621 2.01  E 

Interoperability  and  Supportabiiity  of  Information  Technology  and  National 
Security  Systems 

15  Dec  08 

AF1 10-601 

Operational  Capability  Requirements  Development 

12  JullO 

AF1 10-602 

Determining  Mission  Capability  &  Supportabiiity  Requirements 

18  Mar  05 

AFI 63-1201 

Life  Cycle  Systems  Engineering 

23  Jul  07 

AFHSIG  Strategy 

AF  HSI  Office  Strategy 

Dec  08 
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AF  FY09  Human  Systems  Integration  Management  Plan  (Annex  to  the  OSD 

HSI  Management  Plan) 
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Document  No 

Standard  Title 

Issue 

MIL-STD-1472F 

Department  of  Defense  Design  Criteria  Standard:  Human  Engineering 

23  Auq  99 

MIL-STD-1908B 

Definitions  of  Human  Factors  Terms 

16  Aug  99 

SMC-S-023 

Human  Computer  Interface  Design  Gritena  Vol  1:  User  Interface 

Requirements 

19  Mar  10 

SMC-S-023 

Human  Computer  Interface  Design  Criteria  Vol  II:  Space  System  Operations 
Displays 

19  Mar  10 

Document  No 

Guidance  Title 

Issue 

DAG,  Chapter  2,  Chapter 

6 

The  Defense  Acquisition  Guidebook,  Human  Systems  Integration 

05  May  10 

DcD-HDBK-743A 

Anthropometry  of  U  S  Military  Personnel 

13  Feb  91 

DoD  TAFIM,  Vo!.  8 

DoD  Technical  Architecture  Framework  for  Information  Management,  Volume 

8:  DoD  Human  Computer  Interface  Style  Guide  Version  3.0 

30  Apr  96 

CJCSM  3170.01 

Operation  of  tine  Joint  Capabilities  Integration  and  Development  System 

01  May  07 

MIL-FIDBK-759C 

Department  of  Defense  Handbook  For  Human  Engineering  Design  Guidelines 

31  Jul  95 

MIL-HDBK-761A 

Human  Engineenng  Guidelines  for  Management  Information  Systems 

30  Sep  89 

MIL-HDBK46855A 

Human  Engineering  Program  Process  and  Procedures 

17  May  99 

AFI 63-101 

Acquisition  and  Sustainment  Life  Cycle  Management 

22  Mar  11 

EIA-FEB1 

Human  Engineenng  -  Principles  and  Practices 

Jun02 

When  analyzing  and  evaluating  HSI  requirements,  the  HSI  manager  must  fully  understand  the  seven  HSI 
domains,  the  integration  between  these  domains,  as  well  as  the  interrelation  with  core  acquisition,  engineering 
and  program  management  processes.  Tliis  comprehensive  integration  is  the  key  to  a  successful  HSI  strategy 
and  realization.  The  seven  domains  of  HSI  include:  1)  Manpow  er,  2)  Personnel,  3)  Training.  4)  Environment. 
Safety  and  Occupational  Health  (ESOH),  5)  Human  Factors  Engineering,  6)  Survivability,  and  7)  Habitability. 
A  brief  description  of  each  of  the  domains  is  provided  below. 


Manpower 

Manpower  factors  ultimately  pertain  to  the  number  and  mix  of  military  and  DoD  civilian  personnel  and 
contract  support  that  is  necessary  to  operate,  maintain,  support  and  provide  training  for  the  system  or 
equipment.  This  number  is  derived  from  the  job  tasks,  op  er  alien/ maintenance  rates,  associated  workload  and 
operational  conditions  of  the  proposed /awarded  contract.  In  generating  the  number  and  mix.  DoD  Directive 
5000.01  mandates  program  projections  of  dollars  and  manpower  to  be  realistic  and  based  upon  timely  studies 
and  analyses.  In  the  end.  the  definitive  goal  is  to  identify  shortfalls  that  may  adversely  impact  the  execution  of 
a  program,  and  to  determine  the  most  efficient  and  cost  effective  number  arid  mix  of  people  required 
authorized  and  available  to  operate,  maintain,  support,  and  provide  training  for  a  system  or  equipment. 


Personnel 

HSI  personnel  factors  include  human  aptitude,  knowledge,  skills,  abilities  (KSAs).  and  experience  levels 
requited  to  properly  perform  job  tasks.  The  purpose  of  identifying  these  personnel  factors  in  the  acquisition 
process  is  to  ensure  a  system  or  equipment  is  designed  with  the  target  audience  in  mind  and  conforms  to  the 
capabilities  and  limitations  of  a  specified  user  population  that  is  expected  to  be  in  place  at  The  time  the  system 
is  fielded. 


Personnel  Survivability  and  Force  Protection 
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Survivability  involves  a  system's  ability  to  withstand  man-made  or  natural  hostile  enviromnents  without 
a  bolting  the  mission,  suffering  acute  c bi  onic  illness,  disability  or  death.  Survivability  andPoree  Protection  are 
statutory  Key  Performance  Parameters  (KPP),  applicable  to  all  maimed  systems.  JCIDS  Manual,  enclosure  B, 
para  2a.  31  Jan  2011  update  states  “[survivability]  includes  attributes  such  as  speed,  maneuverability, 
detectability,  and  countermeasures  that  reduce  a  system's  likelihood  of  being  engaged  by  hostile  fire,  as  well  as 
attributes  such  as  armor  and  redundancy  of  critical  components  that  redttce  the  system’s  vulnerability  if  it  is  hit 
by  hostile  fire.”  While  survivability  ad  chesses  maimed  systems  and  then  ability  or  hardening  against  hostile 
fire,  force  protection  KPP  attempts  to  mitigate  hostile  actions  against  friendly  personnel,  military  and  civilian, 
to  comply  with  the  congressional  direction.  Reported  in  System  Threat  Analysis  Report  (STAR),  all  systems 
must  be  assessed  for  expected  threats  and  vulnerabilities  in  the  earliest  possible  phase  of  acquisition  using  a 
cost-effective  combination  of  analysis,  modeling  and  simulation,  and  testing. 

Training 

This  domain  refers  to  the  learning  process  by  which  personnel  individually  or  collectively  acquires  or  enhances 
pre-determined  job-relevant  KSAs  by  developing  then  cognitive,  physical,  sensoiy,  and  team  dynamic 
abilities.  It  also  includes  “tools”  used  to  provide  the  learning  experiences  such  as  job  performance  aids, 
simulators,  computer  based  interactive  courseware  and  electronic  manuals,  as  wTeli  as  actual  equipment.  The 
paramount  goal  is  to  develop  and  su stain  a  ready,  well- trained  individnal/imit,  while  strongly  heeding  options 
to  reduce  life-cycle  costs. 

Human  Factors  Engineering  (HFE) 

The  concept  of  HFE  is  to  understand  competencies  required  for  a  particular  job,  and  to  help  identify  if 
requirements  for  KSAs  exceed  what  the  user  can  provide.  As  a  result,  it  distinguishes  deficiencies  that  will 
lead  to  training  or  operational  problems  ahead  of  time,  hi  other  words,  HFE  is  primarily  concerned  with 
designing  human-machine  interfaces  consistent  with  the  KSAs  of  the  user  population. 

Safety  &  Occupational  Health  (ESOH) 

The  primary  piupose  of  ESOH  is  to  concentrate  on  system  design  features  that  minimize  the  potential  for 
mishaps  causing  death  or  injury  to  operators  and  mamtainers  or  threaten  the  survival  or  operation  of  the 
systems.  It  takes  into  account  the  conditions  in  and  around  the  system  and  the  operational  context  witliin 
which  the  system  will  be  operated  and  supported  (the  environment)  and  its  impact  on  human  ability  to  function 
as  part  of  the  system.  In  addition,  it  w7orks  toward  achieving  system  design  features  that  serve  to  minimize  the 
risk  of  injury,  acute  or  chronic  illness,  or  disability,  as  w7ell  as  factors  reducing  job  performance  of  personnel 
who  operate,  maintain,  or  support  the  system. 


Habitability 

The  living  and  working  conditions  that  are  necessary  to  sustain  the  morale,  safety,  health,  and  comfort  of  the 
user  population  are  the  characteristics  of  the  habitability  domain.  These  factors  directly  contribute  to  personnel 
effectiveness  and  mission  accomplishment  and  it  is  comprised  of  systems,  facilities  and  serv  ices  necessaiy  to 
satisfy  personnel  needs.  It  aims  to  achieve  the  balance  of  maximum  personnel  effectiveness,  support  mission 
performance  and  avoid  personnel  retention  problems. 
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Human  Systems  Integration  Contributions  to  the  Acquisition  Life  Cycle 
Framework 

In  the  modem  technology  era,  systems  and  equipment  have  increasingly  become  more  complex  and 
sophisticated.  Marketing  efforts  for  these  systems  highly  accentuate  new  features,  technical  designs, 
capabilities  and  benefits  of  the  systems,  but  greatly  overshadow  human  elements  that  play  a  critical  role  in  its 
overall  success.  With  respect  to  the  DoD  Acquisition  Life  Cycle,  the  overall  goal  is  to  create  optimized  total 
systems  performance  and  lower  total  ownership  costs,  wliich  is  highly  contingent  upon  the  warfighter’s  ability 
to  use  the  systems  fully  and  effectively  to  accomplish  the  mission.  HSI  is  vital  in  achieving  total  system 
performance  wliile  maximizing  human  capabilities  and  overcoming  human  limitations.  Figure  19  below 
exhibits  the  requirements  and  products  that  need  to  be  developed  with  respect  to  the  acquisition  life  cycle 
framework.  This  graphical  representation  provides  the  HSI  Manager  with  a  bird’s  eye  view  of  how  HSI  fits 
within  the  acquisition  life  cycle  framework.  It  also  illustrates  the  required  support  for  pre  and  post  contract 
award  acquisition  activities  as  well  as  across  the  system  lifecycle  as  it  pertains  to  this  discipline. 

Like  most  disc  ip  lures  in  the  acquisition  process,  ail  effective  HSI  program  is  instilled  in  the  early  planning 
phases  of  the  acquisition  life  cycLe.  The  purpose  of  tliis  planning  process  is  to  anticipate  challenges  and 
obstacles  to  overcome  m  the  HSI  arena.  In  the  past,  a  comprehensive  HSI  process  was  not  instituted  as  p ait  of 
the  Capabilities  Based  Planning  and  Requirements  Development  to  advocate  the  human  aspects  of  a  system 
design.  However,  numerous  investigative  projects  in  recent  years  have  led  to  DoD’s  positioning  to  mandate 
HSI  into  this  practice. 

In  today’s  budget  conscious  and  time  constrained  acquisition  environment,  HSI  capabilities  need  to  be 
addressed  early  in  the  entry  portion  to  the  JCIDS  process  otherwise  known  as  the  Capabilities  Based 
Assessment  (CBA).  The  results  of  the  CBA  are  documented  in  one  of  two  documents.  For  non-materiel 
solutions,  the  output  is  a  joint  Doctrine,  Organization,  Training,  Materiel,  Leadersliip  &  Education,  Personnel 
or  Facilities  (DOTMLPF)  Change  Recommendation  (DCR).  For  materiel  solutions,  ail  Initial  Capabilities 
Document  (ICD)  is  the  preferred  means  of  addressing  and  documenting  CBA  results.  The  CBA  incorporates 
an  analysis  of  all  applicable  HSI  domains  that  may  solve  and/or  mitigate  the  capability  gaps  and  the  HSI 
implications  of  designing,  developing,  fielding  and  sustainment.  Frequently,  the  rationale  for  the 
recommended  solution  (materiel  or  noil-materiel)  and  the  reasoning  as  to  why  other  options  are  inadequate, 
infeasible,  or  undesirable  is  also  documented  in  the  CBA. 

Below  are  the  HSI  activities  and  products  that  are  liighlighted  in  each  of  the  respective  phases  of  the 
Acquisition  lifecycle. 


1.  Materiel  Solution  Analysis*  Many  of  the  critical 
functions  of  HSI  are  front  loaded  in  the  process  and 
resident  in  tills  phase  of  the  acquisition  lifecycle.  The 
primary  objectives  of  this  phase  of  the  acquisition 
lifecycle  are  to  identify  areas  of  potential  HSI  concerns 
and  to  ensure  that  HSI-related  goals,  objectives,  critical 
design  issues  and  metrics  are  addressed.  The  results  of  these  efforts  are  used  in  the  early  Analysis  of 
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PMff  Acquisition  Strategy,  AoA;  APB,  SSP,  STP 

Market  Research _ 

JCD _ 

SEP,  ICMP  _ 

PESHE.  MHA _ 

ORff  COEAr  IMP,  ME 


Hum  a  n  Sys  terns  SMC  Speck i  /  fy  Engi  ?  /  eeri  ng  Discipl i  lies  111 

Alternatives  (AoAs)  to  identify  Non -D e velop mental  Items  (NDIs)  and/or  Commercial  Off  The  Shelf 
(COTS)  products  that  are  appropriate  for  the  system  design.  In  addition,  the  findings  of  the  AoA  are  also 
incorporated  in  market  research  that  is  conducted  to  ensure  proper  identification  and  representation  of  HSI 
requirements. 

The  SMC  HSI  Manager  must  comply  with  the  provisions  of  DoDI  5000.02.  Enclosure  8.  and  ensure  HSI 
planning  is  summarized  in  the  Acquisition  Strategy  and  reflected  hi  the  Systems  Engineering  Plan  (SEP). 
In  general,  the  Acquisition  Strategy  must  address  HSI  issues  that  adversely  impact  the  program's  ability  to 
successfully  execute  and,  ultimately,  meet  the  war  fighters  needs.  It  must  highlight  modifications  to  the 
KSAs  of  military  occupational  specialties  for  system  operators,  maintainers,  or  support  persoiuiel  or 
additional  skill  indicators,  or  issues  relating  to  hard-to-fill  occupations.  It  must  incorporate  a  thorough 
investigation  of  each  of  the  7  HSI  domains  and  their  relevance  to  the  acquisition.  In  addition,  the 
Acquisition  Strategy  must  summarize  planned  steps  (e.g.,  contract  deliverables)  to  ensure  HFE  is 
employed  dining  systems  engineering  throughout  the  life  of  the  program  in  order  to  provide  effective 
human-machine  interfaces  and  meet  HFE  and  other  HSI  requirements. 

As  part  of  the  risk  assessment  section  of  the  Acquisition  Strategy,  die  HSI  Manager  is  required  to 
amalgamate  the  Manpower  Estimate  (ME).  The  ME  is  used  to  reflect  manpower  affordability  in  terms  of 
military  end  strength  (including  force  structure  and  student  end  strength)  and  Chilian  work  years 
beginning  at  Milestone  B.  The  ME  identifies,  as  risks,  the  periods  when  man  power  increases  are  required 
to  support  a  major  program  or  when  manpower  shortfalls  exist.  Within  the  scope  of  HSI,  additional 
attention  is  required  when  fabricating  the  Life  Cycle  Sustainment  Plan  (LCSP).  The  HSI  Manager  must 
summarize  plans  for  survivability  and  addr  ess  the  risks  and  mitigation  plans  in  the  LCSP.  hi  addition,  the 
HSI  Manager  needs  to  also  take  into  account  habitability  factors  and  issues  that  may  potentially  impact 
morale,  safety,  health  or  comfort,  or  degrade  personnel  performance,  unit  readiness,  or  result  hi 
recruitment  or  retention  problems. 

Whether  the  intent  of  the  acquisition  program  is  to  establish  a  new7  capability,  improve  an  existing  one.  or 
exploit  an  opportunity  to  reduce  costs  or  enhance  performance,  one  of  the  most  prominent  documents  hi 
this  phase  is  the  Initial  Capabilities  Document  (ICD),  a  part  of  the  Joint  Capabilities  Integration 
Development  System  (JCEDS)  process.  As  indicated  above,  the  ICD  is  the  product  of  a  materiel  solutions 
derived  from  the  CBA.  The  ICD  provides  a  critical  medium  for  discussion  on  training  requirements  that  is 
relevant  throughout  the  system's  entire  acquisition  life  cycle  and  the  ensuing  capabilities  documents.  The 
HSI  Manager  works  with  APSPC  to  ensure  that  the  DOTMLPF  section  of  the  ICD  describes  all  of  the 
relevant  domains  of  HSI  including  the  key  boundary  conditions  and  operational  environments  that  hup  act 
how7  the  system  is  employed  to  satisfy  the  mission  need.  Key  boundary  conditions  within  which  the  AoA 
is  to  be  performed  include  critical  manpower,  personnel,  framing,  environment,  safety,  occupational 
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health,  hmnan  factors,  habitability  and  survivability  factors  that  have  a  major  impact  on  a  systems 
performance  and  life-cycle  costs.  Additional  HSI  concepts  to  be  considered  include  recommendations  on 
the  type  of  materiel  approach  preferred  for  each  capability  gap.  In  essence,  the  ICD  must  include 
language  that  baselines  HSI  considerations  for  the  system  acquisition.  The  MS  A  Phase  -  SMC 
Acquisition  Products  table  exhibits  the  products  that  are  produced  during  the  Materiel  Solution  Analysis 
phase. 

2.  Technology  Development,  hi  this  phase  of  the 
acquisition  life  cycle,  HSI  continues  to  play  a  critical  role 
in  the  development  of  a  system  and  must  be  discussed  in 
various  acquisition  documents.  One  of  the  primary 
documents  That  need  to  address  HSI  concerns  is  the 
Capability  Development  Document  (CDD).  An  HSI 
Manager  collaborates  with  the  developers  of  the  CDD 
and  the  Program  Office  Systems  Engineers  to  ensure  that  the  CDD  and  the  system  specification  of 
requirements  (technical  requirements  document  to  be  use  in  the  planned  acquisition)  incorporates 
important  discussions  regarding  HSI  including  the  specification  of  hmnan- in-the -loop  requirements  (e.g.. 
''human  in  control,”  "manual  override,”  or  “completely  autonomous  operations.”  The  HSI  Manager  must 
also  identify  operational  considerations  that  affect  sensory  processes  (sensory  requirements),  as  well  as 
applicable  survivability  parameters,  including  the  requirements  to  eliminate  significant  risks  of  fratricide 
or  detectability,  or  to  be  survivable  in  a  chemical,  biological,  radiological,  nuclear  (CBRN)  battlefield. 

The  HSI  Manager  also  ensures  that  the  CDD  discusses  specific  system  training  requirements,  the  training 
Key  Performance  Parameters  (KPPs)  and  additional  performance  attributes  in  tlireshold -objective  format. 
The  training  must  allow  interactions  between  platforms  or  units  (e.g.  through  advanced  simulation  and 
virtual  exercises)  and  provide  training  realism  to  include  threats  (e.g.  virtual  and  surrogate),  a  realistic 
electronic  warfare  enviromnent,  communications,  and  weapons.  It  must  also  consider  embedded  training 
capabilities  that  do  not  degrade  system  performance  below  threshold  values  nor  degrade  the 
maintainability  or  component  life  of  the  system.  The  HSI  Manager  works  closely  with  the  systems 
engineers  to  derive  the  HSI  systems  specification  of  requirements  from  the  C  DD  and  known  technology, 
operational,  and  sustainment  constraints. 

A  summary  of  DOTMPLF  implications  associated  with  fielding  the  system  must  be  documented  in  the 
CDD  as  well  as  any  capabilities -oriented  performance-based  HSI  requirements  that  drive  design,  cost, 
and/or  risk.  It  must  also  document  attainment  of  the  Initial  Operating  Capability  (IOC)  and  the  training 
capabilities  that  are  embedded  and  met  by  IOC.  The  CDD  also  needs  to  address  an  embedded 
performance  measurement  capability  to  support  immediate  feedback  to  the  operator s/maintainers  and 
possibly  to  serve  as  a  readiness  measure  for  the  unit  commander,  Lastly,  the  CDD  must  address  the 
training  logistics  necessary  to  support  the  training  concept  (e.g.,  requirements  for  new  or  upgrades  to 
existing  training  facilities.) 

HSI  issues  and  concerns  are  also  incorporated  into  the  Test  &  Evaluation  Management  Plan  (TEMP)  and 
related  documents  (e.g.,  SEP.  LCMP,  System  Safety  Hazard  Analysis,  System  Training  Plan  and 
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Updates  to  ASP,  APB _ 

CARD  Development _ 

CDD _ 

TEMP,  MER _ 

RFP,  SOW,  SCO,  PWS,  CDRLs.  ACTDs  _ 

Detailed  HSI  planning:  SEP,  LCMP,  TEMP,  SSP,  STP 
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specifications),  which  eventually  translates  these  requirements  to  the  RFP.  SOW  and  contract 
documentation.  Essentially,  this  process  integrates  HSI  requirements  into  the  various  plans  and  ensures 
full  consideration  has  been  given  throughout  the  planning  process  in  designing  the  system. 

HSI  capabilities  must  be  specified  in  measurable,  testable,  per fomiance -based  language  that  is  specific  to 
the  system  and  mission  performance.  The  result  of  setting  specific,  quantifiable  HSI 
parameters/requirements  in  the  CDD  is  that  it  assists  in  the  establishment  of  test  criterion  later  hi  the 
TEMP.  As  trade-offs  are  made  and  plans  for  the  system  mature,  the  CDD  and  all  capabilities  and 
acquisition  documents  must  become  more  specific  and  reflect  the  refinement  and  integr  ation  of  program 
objectives.  The  table  above  displays  the  requisite  documentation  that  is  generated  tliroughout  the 
acquisition  lifecycle  as  it  relates  to  HSI. 

3.  Engineering  &  Manufacturing  Development*  The 
purpose  of  Tills  next  phase  of  the  acquisition  lifecycle  is  to 
develop  a  system  or  an  increment  of  capability,  develop 
an  affordable  and  executable  manufacturing  process,  as 
well  as  implement  human  systems  integration  amongst  a 
host  of  other  critical  events.  It  is  during  tills  phase  that 
system  design  efforts  lock  in  the  operations  and  support 
costs,  which  amounts  to  approximately  60%  of  the  systems  overall  life  cycle  costs.  Therefore,  the  HSI 
Manager  needs  to  employ  human  factors  engineering  to  design  systems  that  require  minimal  manpower, 
provide  effective  training,  can  be  efficiently  operated  and  used,  and  meets  all  of  the  HSI  requirements  as 
specified  in  DoDI  5000.02  in  achieving  the  overall  goal  of  total  optimization  and  minimized  ownership 
cost. 

As  a  follow  up  to  the  CDD,  the  HSI  Manager  must  continue  to  support  the  inclusion  of  HSI  in  another 
JCIDS  capabilities  document  known  as  the  Capability  Production  Document  (CPD)  hi  this  phase,  hi  the 
CPD,  the  HSI  Manager  provides  a  level  of  refinement  of  performance  attributes  and  KPPs  validated  in  the 
CDD.  The  HSI  assists  AFSPC  to  ensure  that  the  CPD  specifies  “safe  limits”  for  environment,  safety  and 
health  hazards,  while  also  providing  updates  to  the  CPD  regarding  KPPs  and  key  system  attributes  , 
DOTMLPF  implications,  and,  of  course,  cap  abilities -oriented  performance -based  HSI  requirements  that 
are  driving  design,  cost  and/or  risk. 

In  summary,  the  EMD  phase  is  the  period  in  the  acquisition  process  in  which  potential  human  related 
shortfalls  and  failures  in  human-mac  lime  integration  are  identified.  The  HSI  Manager  is  responsible  for 
updating  HSI  in  all  program  acquisition  documentation  to  include  the  latest  system  specifications/techuical 
requirements  documents,  integration  strategy,  analyses  of  training  and  support  requirements,  as  well  as 
developing,  executing  and  coordinating  with  program  management,  mitigation  strategies  for  those 
shortfalls  and  failures. 
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4.  Production  &  Deployment,  Operations  &  Support*  In 
the  PD  phase,  the  primary  objective  as  it  pertains  to  HSI 
is  to  ensure  that  the  production  version  of  the  system 
continues  to  meet  the  human  performance  criteria 
established  and  tested  during  the  EMD  phase.  This  is 
predominantly  accomplished  through  Test  &  Evaluation 
(T&E)  and  demonstration  efforts,  which  verifies  the  user- 
system  interface  and  procedures  are  properly  designed  so  that  the  system  can  be  operated,  maintained, 
supported  and  controlled  in  its  intended  operational  environment  by  typical  users. 

The  main  objective  of  the  OS  phase  is  to  execute  a  support  program  that  meets  operational  support 
performance  requirements  and  sustains  the  system  in  the  most  cost-effective  maimer  over  its  total  life 
cycle.  As  previously  stated,  approximately  60%  of  a  system's  total  costs  are  generated  during  this  phase. 
In  an  effort  to  obtain  total  system  optimization  and  the  most  cost-effective  solutions,  it  is  ever  more  critical 
to  heed  HSI  considerations  particularly  hi  designing  effective  system  modifications  to  include  training, 
support  ability,  interoperability  and  maintenance  fimetions.  Obviously,  the  lack  of  appropriate  HSI 
involvement  in  the  design  can  result  in  system  shortcomings  that  requite  costly  redesign,  produce 
substandard  system  performance  and  potentially  precipitate  system  failures  endangering  life  and 
equipment. 

HSI's  Contributions  to  the  Engineering  Life  Cycle 

Relationship  to  the  SE  Organization 

HSI  is  included  as  a  vital  process  within  systems  engineering  and  must  be  implemented  throughout  the  systems 
engineering  life  cycle  to  "balance  total  system  performance  (hardware,  software  and  human).  Operational 
Safety,  Suitability  &  Effectiveness  (OSS&E)  assurance,  survivability,  safety  and  affordability.'’  Throughout 
the  systems  engineering  process,  technical  analyses  are  constantly  performed  iteratively  to  define  successively 
lower  functional  and  performance  requirements.  The  goal  is  to  identify  functional  interfaces  and  to  allocate 
functions  to  components  of  the  system  (e.g.,  hardware,  software  and  human).  Similarly,  requirements  analyses 
are  conducted  iteratively  in  conjunction  with  logical  analysis  to  develop  and  refine  system  level  performance 
requirements,  identify  external  interfaces,  and  provide  traceability  among  user  requirements  and  design 
requirements.  With  respect  to  HSI  and  the  systems  engineering  process,  human-machine  interfaces  must  be 
identified  as  part  of  this  fimctional  allocation  process. 

An  HSI  Engineer  must  ensure  the  Critical  Operational  Issues  (COIs),  Measures  of  Effectiveness  (MOEs),  and 
Measures  of  Performance  (MOPs)  are  constantly  addressed  throughout  the  engineering  life  cycle.  More 
importantly,  the  HSI  Engineer  needs  to  be  able  to  relate  these  HSI  concerns  and  map  its  impact  to  the  Concept 
of  Operations  (CONOPS)  as  well  as  the  System  Thre  at  Asse  ssment  Report  (STAR). 

It  is  the  HSI  Engineer's  responsibility  to  coordinate  with  the  Systems  Engineer  from  a  technical  perspective  to 
ensure  strong  consideration  is  also  given  to  HSI  standards  especially  when  uniform  configuration  is  necessary 
for  ease  of  operation,  safety,  or  training  purposes.  In  developing  an  efficient,  cost-effective  system,  the  HSI 
Engineer  must  actively  partake  in  the  major  technical  reviews,  as  applicable  The  following  is  a  list  of  reviews, 
winch  is  not  all  inclusive,  that  the  HSI  Engineer  is  highly  recommended  to  attend  and  participate: 
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•  Alternative  System  Review  (concept  exploration  phase) 

•  System  Requirements  Review  (program  definition  and  risk  reduction  phase) 

•  System  Functional  Review  (as  appropriate  to  the  acquisition) 

•  Preliminary  Design  Review  (as  appropriate  to  the  acquisition) 

•  Critical  Design  Review  (as  appropriate  to  the  acquisition) 

■  System  Verification  Review  (as  appropriate  to  the  acquisition) 

It  is  also  imperative  that  the  HSI  Engineer  not  limit  his  participation  to  just  the  major  reviews,  but  additionally 
participates  in  subsystem  reviews  including,  where  applicable,  software  specification,  test  readiness,  and 
fimctional  reviews  (e.g.,  support,  training,  systems  engineering,  test,  and  manufacturing  reviews). 

The  HSI  Engineer  ensures  that  each  HSI  SED  contribution  is  timely,  adequate,  consistent,  and  compliant.  The 
HSI  Engineer  ensures  that  HSI  contributions  are  channeled  through  the  Systems  Engineering  Analyses  and 
Control  activity.  Systems  Engineers  manage  the  engineering  process  and  activities  depicted  in  Figure  3  while 
the  HSI  Engineer  contributes  to  this  process.  The  HSI  Engineer  supports  concept  and  architecture  development 
and  analyses;  modeling  and  simulation  efforts;  technology  studies,  as  well  as  develop  s/de  rives  their 
requirements  and  supports  the  requirements  analyses  and  allocations  process.  The  HSI  Engineer  participates  in 
technical  studies  and  solutions  trades  when  HSI  is  a  factor.  They  provide  design  analyses  contributions  to 
determine  and  adjust  HSI  allocations,  update  HSI  predictions,  and  ensure  confidence  in  attaining  HSI 
requirements  through  analyses,  demo,  and  test. 

The  HSI  Engineer  works  closely  with  the  System  Engineers  performing  interface  analyses,  fimctional  analyses, 
and  the  integration  and  verification  and  validation  planning  and  execution.  The  SE  conducts  the  management 
and  control  functions  and  integrates  all  engineering  functions  through  the  fir  11  system  life  cycle. 

The  HSI  Engineer  participates  in  the  systems  engineering  process  to  help  produce  the  proper  balance  between 
system  performance  and  cost  to  ensure  that  requirements  remain  at  affordable  levels.  His  analysis  of 
manpower,  personnel,  training,  and  supportability  analyses  is  conducted  as  an  integral  part  of  the  systems 
engineering  process  throughout  the  acquisition  life  cycle. 

Relationship  to  other  SEDs 

The  HSI  Engineer  ensures  that  solid  technical  contribution  to  the  overall  engineering  advances  and  is 
appropriately  applied  through  systematic  control,  collaboration  and  sharing  across  the  organization.  The  HSI 
Engineer's  contributions  must  be  timed  and  applied  in  conjunction  to  other  Specialty  Engineers’  performance 
of  their  unique  contributions,  while  being  provided  to  technical  and  pr  ogram  management  for  decision  making. 
The  following  paragraphs  demonstrate  key  interactions  between  the  HSI  Engineer  and  the  various  Specialty 
Engineers. 

In  every  operational  system,  people  play  a  significant  role  hi  the  system's  effectiveness  and  success.  However, 
success  is  often  attained  when  a  system  can  readily  expect  consistent,  predictable  performance  from  equipment 
and  personnel.  A1  though,  it  is  certainly  easier  to  produce  consistent  results  over  time  with  equipment,  people 
process  information,  communicate  differently,  and  derive  decisions  in  a  variety  of  ways  that  is  harder  to 
predict.  As  a  result,  it  is  easy  to  recognize  that  human  systems  integration  often  overlaps  with  the  reliability, 
availability,  and  maintaina  bility  (RAM)  critical  process  in  achieving  the  required  level  of  RAM  of  personnel 
and  equipment  combination.  The  HSI  Engineer  teams  with  the  RAM  engineer  to  perform  failure  and  error 
analyses  aimed  at  determining  and  evaluating  potential  personnel  and  equipment  related  failure  modes. 
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Personnel  safety  is  also  of  paramount  consideration  during  the  design-development  phases  for  any  system. 
Hazardous  items  and  conditions  must  be  identified  and  either  eliminated  in  the  design  of  the  system  or 
mitigated  through  established  instructions,  in  the  work,  test,  maintenance  or  operational  procedures.  The  HSI 
Engineer  needs  to  collaborate  with  the  System  Safety  Engineer  to  address  the  system  safety  requirements, 
while  being  sensitive  to  the  human  factors  critical  process,  which  includes  manpower,  personnel,  training  and 
environment,  safety  and  occupational  health  (ESOH)  hazards. 

HSI  is  also  referred  to  as  the  science  of  analysis  and  optimization  of  human  characteristics  and  capabilities  for 
integration  with  machine  characteristics  and  capabilities  in  order  to  provide  the  most  effective  integrated 
human-machine  system  capable  of  accomplishing  specified  functions.  From  a  logistics  perspective,  design 
considerations  must  be  given  to  antluopometric  factors  (e.g.  physical  dimensions  of  the  human  being),  human 
sensory  factors  (e.g,,  vision  and  hearing  capabilities),  physiological  factors  (e.g.  human  needs,  expectations, 
motivation)  and  then  interrelationships.  As  a  result,  the  HSI  Engineer  must  also  forge  a  strong  relationship 
with  the  Acquisition  Logistics  Engineer  and  Logistics  Support  Analyst  and  ensure  incorporation  of  HSI  data 
into  Logistic  Management  Information  (LMI).  HSI  evaluation  as  paif  of  the  Integrated  Logistic  Support  (ILS) 
process  provides  the  program  office  with  the  capability  to  ensure  timely  awareness  of  potential  deficiencies 
requiring  immediate  and  corrective  action.  It  also  provides  an  effective  methodology  for  evaluating  risk,  life 
cycle  cost,  supportability.  HSI,  and  support  systems’  performance  from  a  total  life  cycle  management 
perspective. 

The  HSI  Engineer  must  also  ensure  a  system  is  designed  with  features  that  reduce  the  risk  of  fratricide, 
detection,  and  the  probability  of  being  attacked.  It  must  also  enable  the  crew  to  withstand  man-made  hostile 
environments  without  a  boiling  the  mission  or  suffering  acute  chronic  illness,  disability  or  death.  This  can  be 
achieved  through  close  coord  illation  with  a  Survivability  Engineer 

In  systems  where  software  determines  part  of  the  human  interface,  the  HSI  Engineer  must  also  collaborate 
closely  with  the  Software  Engineers  and  ensure  the  application  of  HSI  principles  to  the  softw  are  design.  These 
same  principles  must  also  be  applied  to  the  development  of  maintenance  and  training  manuals  (electronic  or 
liaid  copy)  to  ensure  thoroughness,  technical  accuracy,  suitable  format  of  information  presentation,  appropriate 
reading  level,  appropriate  level  of  technical  sophistication,  clarity,  and  suitable  quality  of  illustrations. 

The  HSI  Engineer  is  also  required  to  establish  solid  coordination  with  T&E  Engineers  hi  establishing  and 
conducting  a  T&E  program  to  (1)  demonstr  ate  conformance  of  system,  equipment,  and  facility  design  to  HSI 
design  criteria;  (2)  confir  m  compliance  with  system  performance  requirements  where  personnel  performance  is 
a  system  performance  determinant;  (3)  secure  quantitative  measures  of  system  performance  that  are  a  function 
of  tlie  human  interaction  with  equipment;  and  (4)  determine  whether  undesirable  design  or  procedural  features 
have  been  introduced.  Deficiencies  encountered  in  DT&E  and  IOT&E  shall  be  resolved  and  fixes  verified. 

Tools  Selection  and  Use 

The  HSI  Engineer  considers  effectiveness  and 
efficiencies  gained  by  selecting  and  using  the 
best  choice  of  HSI  tools  considering  the  HSI  tool 
requirements  possibly  for  HSI  interface 
verifications,  requirements  analyses,  information 


Typical  HSI  Functions  Requiring  Tools 


Modeling  &  Simulations _ 

HSI  Requirements  Analyses _ 

Experiment  Design,  Growth,  and  Life  Data  Analysis _ 

Manpower  Training  Research  information  Systems  (MATRIS) 

Crew  System  Ergonomics  Information  Analysis  Center  (CSERIAC) 
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Engineering  Activities  and  Products  over  the  Life  Cycle 

The  following  subsections  delineate  HSI  contributions  to  engineering  activities  and  technical  products  by  DOD 
acquisition  phase. 

1.  Materiel  Solution  Analysis*  During  tills 
phase  the  HSI  Engineer  may  provide  inputs 
to  and  support  the  Capabilities  Based 
Assessment  process  and  the  JCIDS  process. 

The  interactions  with  AFSPCs  JCIDS 
process  are  described  hi  the  previous 
section.  The  HSI  Engineer  contributes  to  the 
MSA  Phase  teclmicai  activities  and 
products.  When  warranted,  the  HSI  Engineer 
may  be  required  to  perform  or  support  a  high 
level  human  integration  analysis  of  proposed  material  solutions.  The  HSI  Engineer  provides  and  assesses 
human  engineering  factors  to  trades  and  alternative  analyses  to  ensure  balanced  solutions.  The  HSI 
Engineer  assists  to  identify  and  address  human  integration  related  risks. 


MSA  Phase  -  Technical  Products  Required 


SMC  HSI  Technical 
Products 

HSI  Contributions  to  Other 
Organizations-  Products 

High  level  human  interface 
analysis 

Operational  Concepts 

HSI  inputs  and  factors  for 
concept,  architecture,  technology 
studies,  and  trades 

AoA  Studies 

System  HSI  Reqts  (draft) 

Initial  Capabilities  Doc  (ICD)  Dev 

Roadmap  inputs  -  mitigations  of 
HSI  risks 

DoDAF  CVs,  OVs 

2.  Technology  Develop  men  t.  During  this 
phase  the  HSI  Engineer  continues  to  provide 
inputs  to  and  supports  the  JCIDS  process. 

The  HSI  Engineer  also  supports  all  the 
engineering  activities  highlighted  within  the 
box  titled  Engineering  Activities  for  System 
A  Segment  Development  A  Design  Figure 
19  to  commence  system  definition  and 
development.  The  HSI  Engineer  develops  and  contributes  to  development  of  the  TD  Phase  teclmicai 
products,  as  well  as  the  development  of  CONOPs,  Strategy  and  Doctrine  and  ensures  that  Capability 
Based  Assessments  (CBA)  and  Capability  Requirements  and  Risk  Assessments  (CRRA)  are  properly 
supported  to  facihtate  HSI  inclusion  in  ail  subsequent  steps  of  the  fife  cycle.  The  HSI  Engineer  assists  to 
define  the  system  specification  of  requirements  and  human  systems  integration  related  requirements  at  the 
allocated  level  dining  tliis  phase.  The  HSI  Engineer  works  closely  with  reliability  engineers,  system  safety 
and  other  SEDs  to  ensure  HSI  is  appropriately  factored  mto  their  analytical  contributions. 


TD  Phase  —  Technical  Products  Required 


SMC  HSI  Technical 
Products 

HSI  Contributions  to  Other 
Organizations'  Products 

Inputs  to  System  Concepts 

Operational  Concepts 

Factors  for  Studies/  Trades 

Operational  Assessments 

HSI  Tech  Reqls,  TRD,  SRD, 
Specifications,  ICDs,  Standards 
Selection/  Tailor 

Capabilities  Development  Doc 
(CDD) 

HSI  Analyses  Rpts 

DoDAF  CVs,  OVs 
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3.  Engineering  &  Manufacturing 
Development.  The  HSI  Endue ei  continues 
to  provide  inputs  to  and  support  the  JCIDS 
process,  and  supports  all  the  engineering 
activities  highlighted  within  the  box  titled 
Engineering  Activities  for  Detailed  Design 
Figure  19  to  commence  detailed  systems 
definition  and  development.  The  HSI 
Engineer  develops  and  contributes  to  the 
development  of  the  EMD  Phase  technical 
products.  The  HSI  Engineer  assists  to  define  and  assess  the  system  detailed  requirements.  The  HSI 
supports  design  analyses  and  trades  to  ensure  balanced  solutions  that  take  into  account  HSI,  The  HSI 
Engineer  works  closely  with  reliability  engineers,  system  safety  and  other  SEDs  to  ensure  HSI  is 
appropriately  factored  into  their  analytical  contributions.  The  HSI  Engineer  supports  the  planning  and 
conduct  of  operational  and  sustainment  demonstrations  where  the  human  niter  face  is  potential  critical. 

4*  Production  &  Deployment,  Operations  & 

Support  The  HSI  Engineer  continues  to 
provide  inputs  to  and  supports  the  JCIDS 
process.  The  HSI  Engineer  develops  and 
contributes  to  the  development  of  the  P&D  / 

O&S  Phase  technical  products.  The  HSI 
Manager  and  Engineer  must  work  closely 
with  operational,  maintenance,  systems 
engineering,  logistics  and  training  personnel 
prior  to  and  during  Developmental  Test  &  Evaluation  (DT&E),  Initial  Operational  Test  &  Evaluation 
(IOT&E),  Operational  Test  &  Evaluation  (OT&E)  and  Live  Firing  Test  &  Evaluation  (LFT&E).  In 
addition,  the  HSI  Manager  works  to  ensure  all  program  planning  documentation  (e.g.,  TEMP  MER) 
continues  to  be  updated,  refined  and  tailored  towards  the  system. 

HSI  Engineers'  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  then  business  model  and  approach  structure  based  primarily  on  their  program 
objectives,  program  and  technical  challenges,  organizational  structure,  as  well  as  program  and  engineering 
planning  (SEP  plus  detailed  HSI  planning). 

Once  parameters  are  established  in  the  ICD  and  CDD,  it  is  the  HSI  Manager's  responsibility  to  ensure  that  they 
are  addressed  dining  the  systems  engineering  process,  included  in  the  HSI  plan,  and  the  SEP. 

The  HSI  Manager  shall  apply  HSI  to  optimize  total  system  performance,  operational  effectiveness,  suitability, 
survivability,  safety  and  affordability,  and  develop  HSI  planning.  Each  program  is  required  to  have  a 
comprehensive  plan  for  HSI  that  addresses  the  roadmap  as  well  as  documents  analyses,  results,  and  projections 
with  regards  to  HSI  concerns.  This  plan  is  to  be  included  in  the  SEP  or  established  as  a  stand-alone  HSI  plan 
as  the  program(s)  may  require  These  HSI  requirements  must  also  be  identified  in  and  governed  by  other 


P&D  /  O&S  Phase  -  Technical  Products  Required 


SMC  HSI  Technical 
Products 

HSI  Contributions  ro  Other 
Organizations’  Products 

Inputs  tech  baseline  engineering 
changes 

Sup  portability  Analyses  Rpt 

Analyses  of  production  reports 
and  test  reports 

Operational  Assessments 

Transition  &  Fielding  Docs 

HSI  Analyses  Rpts 

V&V/T&E  Reports 

EMD  Phase  —  Technical  Products  Required 


SMC  HSI  Technical 
Products 

HSI  Contributions  to  Other 
Organizations’  Products 

Update  System  Concept 

Operational  Concepts 

Technical  Studies/  Trades 

Operational  Assessments 

System  Tech  Reqts,  TRD,  SRD, 
Spec,  ICDs 

Capabilities  Production  Doc 
(CPD) 

Inputs  to  system,  production, 
fielding,  sustain  design  docs 

DoDAF  CVs,  OVs,  SVs 

HSI  Analyses  Rpts,  models 

Test,  Demo  reports 

Hum  a  n  Sys  terns  SMC  Sperm  l  ty  Engi  n  eeri  ng  Disc  ip? i  nes  187 

programmatic  documentation  such  as  Systems  Training  Plan  and  the  Manpower  Estimate  (ME).  The  HSI 
Manager  and  HSI  Engineer  need  to  ensure  HSI  requirements  are  included  in  performance  specifications  and 
test  criteria.  The  objective  is  to  translate  HSI  thresholds  and  objectives  in  the  capabilities  documents  into 
quantifiable  and  measurable  system  requirements. 

The  HSI  Manager  develops  and  implements  the  HSI  program  planning  to  achieve  HSI  objectives  and 
requirements.  The  planning  defines  the  HSI  tasks  and  functions  to  be  performed  and  products  to  be  developed; 
timing  of  tasks,  task  outputs,  resources  (skills,  tools,  equipment),  and  completion  criteria.  The  HSI  Engineer 
plans  tasks  to  integrate  HSI  activities  within  the  program  office,  between  Contractors  and  stakeholders. 

Program  planning,  budgeting  and  scheduling  data  enable  the  HSI  manager  to  track  the  sequence  of  program 
events  to  determine  if  HSI  inputs  will  have  the  optimum  impact  on  design.  HSI  efforts  must  be  well  planned 
and  must  conform  to  the  overall  program  office  Integrated  Master  Schedule  (IMS).  The  HSI  Manager  must 
also  focus  on  identifying  HSI-related  tradeoffs  and  design  risks  associated  with  various  design  concepts  or 
alternatives  under  construction.  All  major  planning  documents  and  schedules  (Work  Break  Down  Structure 
(WBS),  Operational  Requirements  Document  (QRD),  TEMP,  IMS)  is  required  to  be  reviewed  and  cross 
referenced  to  ensure  that  all  HSI  matters  have  been  identified  and  included. 

HSI  findings  from  design  reviews,  inockup  inspections,  demonstrations,  and  other  early  engineering  tests  must 
be  utilized  in  planning  and  conducting  later  tests.  HSI  test  planning  needs  to  be  directed  toward  verifying  that 
the  system  can  be  operated,  maintained,  supported  and  controlled  by  user  persomiel  hi  its  intended  operational 
environment,  as  well  as  highlight  any  HSI  issues  uncovered.  It  is  critical  that  HSI  issues  be  hsted  at  a 
sufficiently  high  level  hi  the  WBS  to  better  ensure  receipt  of  funding  allocations.  Listing  HSI  issues  at  lowrer 
levels  in  the  WBS  may  result  hi  HSI  concerns  being  overlooked,  deemed  less  important  hi  relation  to  other 
matters,  or  perceived  as  optional.  Ultimately,  tills  introduces  the  risk  of  not  obtaining  the  required  funding  to 
successfully  address  HSI  concerns  and  achieving  total  system  optimization. 

The  HSI  Manager  and  Engineer  must  provide  input  to  and  actively  review  the  Integrated  Master  Plan  (IMP), 
IMS  and  WBS  to  ensure  that  HSI  efforts  are  appropriately  identified  and  scheduled.  This  en sures  that  HSI 
functions  occur  at  the  proper  time  with  respect  to  the  other  program  functions.  Meanwhile,  the  HSI  manager  is 
also  responsible  for  monitor  mg  the  system  baseline  (configuration  management),  and  justifying  the  HSI  budget 
to  the  program  office  on  the  basis  of  anticipated  improvements  hi  performance,  prevention  of  system  problems, 
and  cost  savings.  Additionally,  it  is  essential  that  the  HSI  Manager  be  a  proactive  participant  in  IPTs  and 
working  groups  to  learn  about  HSI  issues,  secure  binding  for  HSI  analyses  and  gain  the  opportunity  to 
influence  design,  and  inform  the  Program  Office  wfiat  HSI  can  do  for  the  program. 

The  HSI  Manager  is  also  responsible  for  coordinating  with  the  requisite  personnel  conducting  Cost  and 
Operational  Effectiveness  Analysis  (COEA),  otherwise  known  as  Analysis  of  Alternatives,  to  ensure  that 
human-related  issues  are  addressed  in  the  financial  considerations  for  all  the  alternative  concepts. 

The  HSI  Engineer  provides  full  support  to  define  the  program  and  teclinical  objectives  wiiere  HSI  challenges 
and  risks  are  known  or  anticipated.  The  HSI  Engineer  assists  to  establish  the  business  model,  develop  program 
planning  and  schedules,  and  define  and  implement  program  processes.  The  HSI  Engineer  ensures  that  the  HSI 
components  of  the  program  are  appropriately  represented  in  the  program  plans,  program  schedules,  WBS,  and 
cost  estimates.  The  HSI  Engineer  also  reports  then’  teclinical  performance  and  progress.  Additionally,  the  HSI 
Engineer  shares  in  the  risk  management  responsibilities  to  identify,  assess,  and  propose  mitigating  actions  of 


1 88  SMC  Specialty  Engineering  Disciplines  Human  Systems 

HSI  related  risks,  and  supports  the  program  manager's  problem  identification,  resolution,  and  decision  making 
processes. 


The  HSI  Manager  and  Engineer  must  continue  to  remain  abreast  of  new  and  emerging  teclmologies  relevant  to 
the  specific  system  being  considered,  as  well  as  be  knowledgeable  of  new  HSI  information  sources  and 


assessment  methodologies  that  may  be  useful  in  performing  analyses  and  making  feasibility  determinations. 


HSI  Managers  and  Engineers  contribute  to  the  development  of 
the  program  management  products  identified  in  the  table. 


SMC  Program  Management  Produci 


PMD _ 

SEP,  IMP,  IMS,  WBS 

Decision-making  &  problem  solving  inputs 

Technical  progression  and  issues  reporting 

LC  Cost  Estimate  (CARDs) _ 

Processes  (Ols);  HSI  Plan _ 

CRRA,  Risk  Management  Inputs 


Mass  Properties 


SMC  Specialty  Engineering  Disciplines 
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Appendix  O  -  Mass  Properties  Engineering 

Mass  Properties  is  an  engineering  discipline  that  is  concerned  with  estimating  weight,  center  of  gravity,  and 
inertia  values  of  various  vehicles,  including  space  vehicles  to  include  the  upper  stage  vehicles,  injection  stages 
satellites,  satellite  payloads,  reentry  vehicles,  launch  vehicles,  ballistic  vehicles,  or  other  veliicles.  Mass 
properties  provide  for  the  control,  determination  and  documentation  of  the  mass  properties  and  mass  properties 
limits  of  space  vehicles  and  their  subsystems  and  components.  The  mass  properties  of  an  item  include  the 
item's  weight  (or  mass),  center  of  gravity  (or  center  of  mass),  mass  moments  of  inertia,  and  mass  products  of 
inertia. 

SMC  Program  Office  Mass  Properties  (MP)  Engineers  have  the  responsibility  to  stand-up  and  execute  the  mass 
properties  efforts  for  the  development  or  modification  of  SMC  space  vehicles.  The  MP  Engineer  ensures 
effective  prediction  of  the  space  veliicle  mass  properties  parameters  to  support  performance  analyses,  stability 
and  control  analyses,  structural  dynamics  and  loads  analyses,  and  other  analyses.  The  MP  Engineer  establishes 
and  implements  a  mass  properties  control  program  with  the  objective  of  meeting  the  space  vehicle  mass 
properties  requirements  for  weight,  center  of  gravity,  mass  moments  of  inertia,  and  mass  products  of  inertia  as 
they  apply.  The  control  of  weight  growth  is  a  continuous  activity  from  system  concept  development  through 
the  last  item  of  production.  However-  a  more  restrictive  definition  usually  refers  to  the  technology  development 
and  EMD  phases  when  most  growth  occurs.  Costly  fixes  and  possible  schedule  delays  are  avoided  when 
weight  prediction  and  control  is  applied  while  defining  alternative  enabling  concepts  or  technologies  and 
determining  the  preferred  solutions.  During  detailed  design,  a  major  effort  is  required  to  keep  the  designers 
attention  focused  on  weight  efficiency. 

Applicable  governance,  standards,  and  guidance 

Policy,  dir  ectives,  and  instructions  that  mandate  system  integrity  typically  apply  to  space  systems  and  require 
specialty  disciplines  such  as  reliability  engineering,  prognostics  and  health  management,  and  rigorous  design 
engineering  including  mass  properties.  For  example,  AFI  63-1201  requires  that  weapon  system  integrity 
programs  be  employed  to  ensure  that  system-level  performance  and  safety  requirements  are  met  under  any 
combination  of  design  usage  environments  throughout  the  operational  life  of  a  system.  Hence,  mass  properties 
design  and  test  criteria  must  be  established  as  it  applies  to  space  vehicles,  launch  vehicles,  and  missiles. 

Table  20  below  identifies  the  significant  governance,  standards,  and  guidance  winch  generally  require  SMC 
compliance  for  MP  Engineering. 

Table  20  Governance,  standards,  and  guidance  that  shape  the  Mass  Properties  Engineering  discipline 


Document  ISTo 

Governance  Title 

Issue 

1  AFI  63-1201  1 

Life  Cycle  Systems  Engineering  1 

23  Jul  07  I 

Document  No 

Standards  Title 

Issue 

AIAA-S-1 20-2006 

Mass  Properties  Control  for  Space  Systems 

01  Dec  06 

SMC-T-002 

Tailoring  Instructions  For  AIAA-S-1 20-2006 

08  Aug  08  ! 

Document  No 

Guidance  Title 

Issue 

MIL-HDBK-1811 

Mass  Properties  Control  For  Space  Vehicles 

12  Aug  98 

SAWE  RP  6 

Standard  Coordinate  Systems  for  Reporting  the  Mass  Properties  of 
Flight  Vehicles 

03  Jun  00 

SAWE  RP  11 

Mass  Properties  Control  For  Space  Vehicles 

03  Jun  00 

CPAT 

Critical  Process  Assessment  Tool  -  Mass  Properties 

18  Sep  06 
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MP  Engineers'  Contributions  to  the  Acquisition  Life  Cycle  Framework 

The  DoD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  The  MP  Engineer  contributions  over  this  life  cycle 
are  best  represented  within  the  acquisition  phase.  Figure  20  provides  the  acquisition  life  cycle  framework 
within  which  MP  Engineers  perform  as  well  as  the  products  that  they  must  develop  or  contribute  to  the  system 
development.  This  figure  along  with  MIL-HDBK-181 1  and  SAWE  recommended  practices  provide  the 
guidance  to  perform  MP  planning,  support  pre  and  post  contract  award  acquisition  activities,  and  perforin  MP 
engine ering  and  control  across  the  system  lifecycle.  The  SMC  Program  Office  establishes  and  implements  MP 
program  strategies  and  objectives  consistent  with  SMC  acquisition  and  program  objectives.  The  Program 
Office  then  develops,  approves,  and  incorporates  the  more  detailed  MP  planning,  the  Mass  Properties  Control 
Plan  (MPCP).  into  the  Test  and  Evaluation  Master  Plan  (TEMP).  Systems  Engineering  Plan  (SEP)  and  higher 
level  inte grated  planning  (e.g.,  IMP,  LCMP,  LCSP)  hi  accordance  with  current  DoD  policy  and  Program 
Office  practices  Hence,  MP  planning  is  firmly  based  on  program  and  technical  objectives,  strategies.  DoD 
mandates  and  instructions,  and  MP  related  specifications  and  practices. 

1*  Materiel  Solution  Analysis.  During  this  phase,  the  MP 
Engineer,  with  the  developmental  engineering  team, 
begins  to  formulate  predictive  models  and  parameters  of 
the  space  vehicle  mass  properties  as  system  concepts  are 
defined  and  provides  inputs  to  and  supports  acquisition 
activities  to  include  development  of  acquisition  strategy, 
technology  development  strategy,  and  data  strategies. 

The  MP  Engineer  provides  inputs  to  the  cost  estimates,  REP  development  for  Contractor  studies,  and 
proposal  evaluation  activities.  The  MP  Engineer  also  contributes  to  the  development  of  the  MSA  Phase 
acquisition  products. 

2*  Techno  logy  Development.  The  MP  Engineer  provides 
inputs  to  and  supports  all  program  acquisition  activities  to 
include  updates  to  the  MPCP  and  inputs  to  the  ASP,  TDS 
and  TEMP.  MP  strategies  are  likely  integral  to  tlie  MP 
controls  to  achieve  system  performance.  The  MP 
Engineer  provides  inputs  to  the  cost  model;  development 
of  the  Cost  Analysis  Requirements  Description  (CARD); 
and  solicitation/RPP  development  and  proposal  evaluation  activities.  The  MP  Engineer  assists  in  the 
preparation  of  contract  requirements  for  contractor  and  subcontractor  MP  controls,  parameter 
determination,  and  developmental  /  qualification  testing  to  meet  MP  and  Program  Office  objectives  and 
requirements.  The  MP  Engineer  also  contributes  to  the  development  and  updates  to  the  TD  Phase 
acquisition  products.  The  MP  Engineer  assesses  the  effectiveness  of  the  Contractor  MP  efforts. 


TD  Phase  -  SMC  Acquisition  Products 


Update  to  MPCF;  Inputs  to  SEP,  LCMP,  TEMP 
Updates  to  ASP,  TDS,  QMS _ 

LC  Cost  Estimate  Update  /  CARD  Development 
Inputs  to  APB _ 

RFP:  MP  tasks  in  PWSf  MP  data  products  in  CDRLs; 
SMC-  MP  standards  -  tailored _ 

SSP:  evaluation  criteria  for  MP 


MSA  Phase  -  SMC  Acquisition  Products 


Prepare  MPCP _ 

Inputs  to  ASP,  TDS,  DMS,  TES _ 

Draft  MPCP;  Inputs  to  SEP,  LCMP _ 

Inputs  to  LC  Cost  Estimate,  CARD _ 

Inputs  to  APB _ 

RFP:  MP  tasks  in  PWS,  MP  data  products  in  CDRLs: 
MP  standard  -  Tailored 
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3.  Engineering  &  Manufacturing  Development.  The  MP 
Engineer  provides  inputs  to  and  supports  all  program 
acquisition  activities  to  include  updates  to  the  ASP,  TDS. 
and  DMS;  updates  to  the  TEMP:  inputs  to  the  cost  model 
and  CARD  to  reflect  the  cost  elements:  inputs  to  the 
APB.  The  MP  Engineer  supports  the  preparation  of 
contract  requirements  such  as  mass  properties 
performance  work  statements;  identification  and  tailoring  of  the  compliance  test  standards:  preparation  of 
the  MP  related  CBRLs  for  submission  of  Contractor  mass  determinations  and  basis,  expected  mass 
growth,  analyses,  methods  of  analysis,  etc.  The  MP  Engineer  also  contributes  to  the  development  and 
updates  to  the  EMD  Phase  acquisition  products. 

4.  Production  &  Deployment,  Operations  &  Support. 

The  MP  Engineer  provides  inputs  to  and  supports  all 
program  acquisition  activities  to  include  updates  to  the 
ASP,  TDS  and  DMS:  inputs  to  the  cost  model  and  CARD 
to  reflect  the  MP  cost  elements  requited.  The  MP 
Engineer  supports  the  preparation  of  eon  tract 
requirements  such  as  MP  performance  work  statements; 
identification  and  tailoring  of  the  MP  standard;  preparation  of  the  MP  related  CDREs  for  submission  of 
Contractor  mass  determinations  and  basis,  expected  mass  growth,  analyses,  methods  of  analysis,  etc.  The 
NIP  Engineer  supports  field  performance  and  sustainment  analyses  to  meet  MP  requirements  and 
objectives.  The  MP  Engineer  ensures  successful  verification  and  validation  of  the  MP  parameters  through 
developmental  and  operational  test  and  evaluation. 


P&D  /  O&S  Phase  -  SMC  Acquisition 
Products 


Updates  to  ASP,  TEMP _ 

MPCP;  inputs  to  SEP,  LCMP _ 

RFP:  MP  tasks  in  PWS,  MP  data  products  in  CDRLs, 
SMC-  MP  standards  -  tailored _ 

CARD  update 


EMD  Phase  -  SMC  Acquisition  Products 


Update  to  TMPCP,  inputs  to  SEP,  LCMF,  TEMP 
Updates  to  ASP,  TDS,  DMS _ 

LC  Cost  Estimate  Update  /  CARD  Development 
Inputs  to  APB _ 

RFP:  MP  tasks  in  PWSf  MP  data  products  in  CDRLs; 
SMC-  MP  standards  -  tailored _ 

SSP:  evaluation  criteria  for  MP 
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Acquisition  Life-Cycle  Process  for  Mass  Pr 
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MP  Engineers1  Contributions  to  the  Engineering  Life  Cycle  Framework 

Relationship  to  the  SE  Organization 

The  MP  Engineer  plans  and  implements  the  space  vehicle  mass  properties  determination  and  control  program 
witlrin  the  context  and  hill  support  of  the  overarching  Systems  Engineering  function.  The  MP  Engineer  ensures 
that  each  mass  properties  contribution  is  timely,  adequate,  consistent,  and  compliant.  The  MP  Engineer  ensures 
that  their  SED  contributions  to  concept  and  architecture  development,  requirements  analyses,  design  trades  and 
analyses,  and  test  are  channeled  tluough  the  Systems  Engineering  Analyses  and  Control  activity.  Systems 
Engineers  manage  the  engineering  process  and  activities  depicted  in  Figure  3  while  the  MP  Engineer 
contributes  to  tliis  process  through  mass  properties  determination,  control,  and  documentation  of  space  vehicles 
and  their  subsystems  and  components.  The  MP  Engineer  ensures  effective  prediction  of  the  space  vehicle  mass 
property  parameters  through  estimated1  c ale ulated/ineasur  ed  mass  properties,  mass  growth  allowance,  analyses, 
and  risk  assessments  to  support  performance  analyses,  stability  and  control  analyses,  and  structural  dynamics 
and  loads  analyses.  The  MP  Engineer  also  works  with  the  System  Engineers  ensuring  mass  properties  factors 
are  integral  to  space  veliicle  design  and  performance  trades. 

Relationship  to  other  SEDs 

The  MP  Engineer  ensures  results  of  mass  properties  are  applied  to  the  overall  engineering  effort  tluough 
systematic  control,  collaboration  and  sharing  across  the  organization  to  facilitate  system  development  and 
implementation.  For  example,  the  testing  results  are  evaluated  to  assess  progress  of  the  design  to  assure  that 
such  items  as  weight  and  balance  bogies  are  being  met.  Early  emphasis  of  mass  properties  and  its  budget 
planning  contributes  to  reduction  of  risk  throughout  the  acquisition  lifecycle.  The  MP  Engineer  also  ensures 
the  spacecraft  weight  is  within  launch  veliicle  capabilities  and  that  the  weight  growth  is  within  the  allocated 
margin. 

MP  Engineers,  by  the  nature  of  their  function,  must  interface  with  all  specialty  disciplines  involved  with  the 
design,  development,  manufacturing,  deployment  and  operation  of  a  system  that  may  impact  the  mass 
properties  of  the  space  veliicle.  MP  Engineer  interactions  include: 

•  Arcliitecture  Engineers  and  Concept  Developers  to  provide  mass  properties  data  to  support  alternative 
analyses  and  ensure  predictive  mass  properties  model  is  current. 

•  Design  Engineers  to  ensure  design  solutions  are  current  for  mass  properties  determinations:  provide 
data  to  designers  for  optimal  component  selection  and  location  for  Space  Veliicle  (SV)  balance: 
provide  segmented  mass  properties  for  structural  and  thermal  analysis. 

•  T&E  Engineer  to  coordinate  the  equipment  and  procedures  for  mass  properties  measurements: 

o  determination  o  f  accuraci  es  re  quire d 

o  determination  and  design  of  test  fixtures  to  meet  requirements 
o  calibration  of  equipment 

o  M&S  -  dynamics  Finite  Element  Modeling  (FEM)  where  mass  properties  data  are  utilized  in 
FEM  to  determine  veliicle  dynamic  response. 

•  Survivability  for  optimum  component  selection  as  well  as  component  and  space  vehicle 
shielding/hardening  methods. 

•  PMP  to  influence  PMP  selections,  packaging  to  reduce  weight. 

•  Reliability  Engineering  to  collaborate  and  attain  balanced  solutions  for  redundancy  decisions 

•  Other  specialists  as  required. 
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Tools  Selection  and  Use 

The  NIP  Engineer  considers  effectiveness  and  efficiencies  gained  by  selecting  and  using  the  best  choice  tools 
consi deling  the  mass  properties  functions  of  MP 
prediction  modeling.  MP  determination  of 
parameters,  MP  database  management  and 
control,  information  sharing,  automated  data 
exchanges  with  other  tools,  etc. 

Engineering  Activities  and  Products  over  the  Life  Cycle 

The  Mass  Properties  Engineer  is  responsible  for  developing  and  implementing  a  mass  properties  determination 
and  control  program  to  provide  analyses  and  support  technical  decisions  to  determine  the  preferred  system 
concept,  viable  technologies,  performance  requirements,  design  solutions.  Establishing  and  controlling  mass 
budgets  and  providing  rigorous  mass  properties  analyses  hi  support  of  the  overall  engineering  is  essential  to 
meet  the  program  performance  and  cost  goals  as  well  as  early  identification  of  potential  program  risks. 

The  following  subsections  delineate  mass  properties  contributions  to  engineering  activities  and  technical 
products  by  DOD  acquisition  phase.  Refer  to  AIAA-S- 120-2006.  MIL-HDBK-181 1,  and  SAWE  recommended 
practices  for  a  more  complete  list  of  MP  Engineering  activities  and  products  that  are  prepared  by  the  Program 
Office  and  their  Contractors, 

1.  Materiel  Solution  Analysis*  During  this 
phase  the  MP  Engineer  supports  the  JCIDS 
process.  The  MP  Engineer,  with  the 
development  engineering  team,  formulates 
predictions  (estimated)  and  parameters  of 
the  space  vehicle  mass  properties  as  system 
concepts  are  defined  and  provides  inputs  to 
and  supports  acquisition  activities  to  include 
development  of  acquisition  strategy, 
technology  development  strategy,  and  data 
strategies.  The  MP  Engineer  initiates  the 
Mass  Properties  Control  Program,  establishes  and  allocates  the  initial  mass  properties  budget,  and 
determines  the  test  strategy  to  maximize  efficiencies.  The  MP  Engineer  also  contributes  to  the 
development  of  the  MSA  Phase  products. 
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SMC  Mass  Properties 
Technical  Products 

MP  Contributions  ro  Other 
Organizations '  Products 

Initial  MP  control  p]an  and 

Process 

Space  vehicle  preferred  enabling 
concept  and  AoA 

Mass  properties  prediction  - 
estimated  +  Wt  growth  allowance 

ICD 

Initial  mass  budget;  target  launch 
vehicle  type;  subsystem  and 
component  mass  allocation 

DoOAF  CVs,  OVs 

Vehicle  performance  analyses 

MP  Requirements  (draft) 

Mitigations  of  MR  risks 

Typical  Mass  Properties  Functions  Requiring  Tools 


MP  Predictive  modeling _ 

Mass  Properties  Requirements  Analyses  &  Allocations 
MP  database  management  and  control _ 

DeveEopment/Qperational  testing 


196  SMC  Spec  fa  l  ft  /  Engirt  eerii  ig  Dis  cipl  i  nes  Mass  Proper  ti  es 

2 .  Technology  Development.  During  this 
phase  the  MP  Engineer  continues  to  support 
the  JCIDS  process.  The  MP  Engineer  also 
supports  the  systems  engineering  activities 
highlighted  within  the  box  titled 

Engineering  Activities  for  Development  & 

Desigrt  Figure  20  to  commence  system 

definition  and  development.  The  Mass 
Properties  Engineer  refines  the  mass 

properties  predictions,  performs  trend 

analyses,  and  evaluates  technology  and 
design  solutions  to  satisfy  systems 
performance  requirements.  The  Mass 

Properties  Engineer  continues  to  derive  and 
apply  mass  properties  parameters  and 
allocations  through  the  requirements  analysis  process  and  assesses  verification  tests  of  prototypes  or 
preprod notion  articles.  The  Mass  Properties  Engineer  supports  the  T&E  and  M&S  planning.  The  Mass 
Properties  Engineer  supports  the  concept,  architectural,  tecluiology  development,  and  engineering  trades 
and  analyses  to  ensure  the  concept,  architectural,  technology  and  design  solutions  are  determined 
considering  mass  properties  influences.  The  MP  Engineer  develops  and  contributes  to  development  of  the 
TD  Phase  technical  products. 

3.  Engineering  8n  Manufacturing 
Development.  During  tins  phase  the  MP 
Engineer  continues  to  support  the  JCIDS 
process.  The  MP  Engineer  supports  the 
systems  engineering  activities  higlilighted 
witliin  the  box  titled  Engineering  Activities 
for  Development  &  Design  Figure  20  to 
commence  detailed  systems  definition  and 
development.  The  MP  Engineer  updates  and 
implements  the  MPCP  and  continues  to 
implement  the  mass  properties  control 
program  to  meet  the  space  vehicle  mass 
properties  requirements  for  weight,  center  of 
gravity,  mass  moments  of  inertia,  and  mass 
products  of  inertia  as  they  apply.  The  MP 
Engineer  updates  the  mass  properties  predictions  (calculated),  refines  the  space  vehicle  mass  properties 
parameters  focusing  on  weight  efficiencies  and  system  performance.  The  MP  Engineer  assesses  test 
methodologies  and  limitations.  Mass  properties  engineering  efforts  are  also  concentrated  on  analyzing  and 
controlling  the  system  design  to  assure  that  1)  the  design  is  evolving  consistent  with  the  MP  weight  and 
balance  requirements  and  allocations.  2)  design  qualification  is  progressing  consistent  with  the  MP 
requirements.  The  MP  Engineer  monitors  contractor's  documentation  such  as  mass  growth  allowance  and 
depletion  schedules,  detailed  mass  properties,  analyses,  and  verification  plans  and  results. 
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4.  Production  &  Deployment,  Operations  & 

Support*  Dining  this  phase.  MP  efforts  are 
concentrated  on  the  evaluation  of  proposed 
engineering  changes,  assessments  of 
production  and  fielding  tests,  and  production 
and  fielding  challenges  that  potentially  alter 
the  baselined  design  weight  and  balance. 

The  MP  Engineer  continues  to  assess  the 
design  to  determine  if  it  meets  the 
contractual  requirements  and  ensures  that 
build  and  integration  activities  do  not  induce  additional  MP  risks.  The  MP  Engineer  provides  inputs  to  and 
supports  the  solicitation/RFP  development  and  proposal  evaluation  activities.  The  MP  Engineer  identifies 
other  contract  requirements:  production  and  operational  test  &  demo  requirements:  operational 
performance  and  sustainment  analyses  to  meet  MP  program  objectives  and  requirements.  The  MP 
Engineer  assists  the  T&E  Engineer  in  the  preparation  of  the  Certificate  of  System  Read  mess  to  enter 
OT&E.  The  MP  Engineer  develops  and  contributes  to  the  development  of  the  P&D  /  O&S  Phase  technical 
products. 

MP  Engineers'  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  their  business  model  and  approach  based  primarily  on  program  objectives, 
technical  challenges,  organizational  structure,  and  required  engineering  planning  including  mass  properties 
engine ering  for  cost-effective  execution. 

The  MP  Engineer  develops  and  implements  a  mass  properties  determination  and  control  approach  to  achieve 
Program  Office  management  objectives  and  requirements.  The  approach,  which  is  documented  in  the  MPCP, 
defines  the  MP  engineering  tasks  and  functions  to  be  performed  and  products  to  be  developed:  timing  of  tasks, 
task  outputs,  resources  (skills,  tools,  equipment,  and  completion  criteria).  The  MP  Engineer  plans  tasks  and 
integrates  the  mass  properties  activities  within  the  Program  Office,  between  Contractors  and  stakeholders.  The 
MP  Engineer  plans  the  tasks  to  support  the  engineering  and  decision  processes:  technical  review  forums: 
support  SE&I  activities,  risk  management,  integration,  and  system  modifications.  Execution  of  the  MP 
Engineer  planning  is  typically  defined  through  ail  Operating  Instruction.  The  MP  provides  fill!  support  to 
define  the  program  and  teclmical  objectives  where  MP  challenges  aud  risks  are  known  or  anticipated.  The 
essential  MP  information  is  provided  to  program  management  to  determine  if  the  program  is  ready  for  frill 
scale  production  or  if  the  design  and  production  processes  need  to  be  refined. 

The  MP  Engineer  assists  to  establish  the  business  model, 
develop  pro-gram  planning  aud  schedules,  and  define  and 
imp  lenient  program  processes.  The  MP  Engineer  ensures  the 
mass  properties  elements  of  the  program  are  appropriately 
represented  in  the  program  plans,  program  schedules,  work 
breakdown  schedules,  cost  estimates.  The  MP  Engineer  also 
reports  their  technical  performance  and  progress.  The  MP 
Engineer  shares  in  the  risk  management  responsibilities  to  identify,  assess,  and  propose  mitigating  actions  of 
MP  related  risks.  They  also  support  the  Program  Manager's  problem  identification,  resolution,  and  decision- 
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making  processes.  Mass  Properties  tasks  that  support  Program  Management  includes  evaluating  and 
monitoring  contractor,  subcontractors  mass  properties  control  efforts. 


EMI/EMC 
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Appendix  P  -  Electromagnetic  interference/  Electromagnetic 
compatibility  Engineering 

A  system  in  development  must  be  compatible  to  all  defined  environments  to  which  they  are  intended  to  be 
exposed.  The  system  must  operate  in  various  operating  modes  and  mission  phases,  white  working 
harmoniously  in  concert  with  other  systems.  Each  system  must  be  electromagnetic  ally  compatible  among  all 
subsystems  and  equipment  within  the  system,  including  the  personnel  that  interact  with  the  system,  and  with 
environments  caused  by  emitters  and  other  electro magire tic  sources  external  to  the  system  to  ensure  safe  and 
proper  operation  and  performance. 

In  the  simplest  terms.  Electromagnetic  interference  (EMI)  is  the  detrimental  effect  stray  radiated 
electromagnetic  energy  has  on  the  performance  of  a  system.  Electromagnetic  compatibility  (EMC)  involves  the 
control  and  reduction  of  this  energy.  Our  space  and  ground  systems  mnst  be  able  to  operate  and  remain  fie e  of 
overstress  and  anomalies  caused  by  either  intentional  or  extraneous  electromagnetic  (EM)  energy  emanating 
within  or  outside  the  system  from  man-made  or  natural  sources,  hi  essence,  EMC  refers  to  the  capability  of 
electrical  and  electronic  systems,  equipment*  and  devices  to  operate  in  then  hit  ended  electromagnetic 
environment  witliin  a  defined  mar  gin  of  safety,  and  at  design  levels  of  performance,  without  suffering  or 
causing  unacceptable  degradation  as  a  result  of  Electromagnetic  Interference  (EMI).  While  EMI  is  concerned 
with  electromagnetic  disturbances  that  interrupt,  obstruct,  degrade  or  limit  the  effective  performance  of 
electronic  or  electrical  systems,  transmission  channels,  equipment  or  devices. 

However  the  Program  Office  EMI/EMC  Engineer  (herein  referred  to  the  EMC  Engineer),  Survivability 
Engineer,  Human  Systems  Integration,  Spectrum  Manager,  and  other  contributors  must  consider  a  broader 
context  of  electromagnetic  environmental  effects  (E3).  E3  encomp asses  the  electromagnetic  effects  addressed 
by  the  disciplines  of  electromagnetic  compatibility  (EMC),  electromagnetic  interference  (EMI), 
electromagnetic  vulnerability  (EMV).  electromagnetic  pulse  (EMP),  electronic  protection  (EP),  electrostatic 
discharge  (ESD),  and  hazards  of  electromagnetic  radiation  to  personnel  (HERP).  ordnance  (HERO),  and 
volatile  materials  (HERP).  lightning,  precipitation  static,  and  electrostatic  discharge.  E3  includes  the 
electromagnetic  effects  generated  by  all  EME  contributors  including  radio  frequency  (RE).  Consideration  of 
these  various  aspects  of  E3  could  be  cmciai  to  fielding  a  system  that  is  electro  magnetic  ally  compatible  with 
itself,  surrounding  systems,  and  the  operational  electromagnetic  environment.  While  EMI,  including 
interference  caused  by  spectrum  management  problems,  can  cause  catastrophic  failures,  the  majority  of 
interference  problems  render  systems  only  partially  effective  reducing  operational  readiness  and  increasing 
costs. 

SMC’s  Programs  establish  and  designate  responsibility  for  managing  and  executing  the  EMI/EMC 
management  program.  Its  responsibilities  include  planning,  supervising  and  ensuring  essential  EMI/EMC  and 
management  efforts  are  integrated  with  various  acquisitions,  management,  &  engineering  processes.  The 
program  office  ensures  effectiveness  and  compliancy  to  the  assorted  policies,  DoD  mandates,  instructions,  and 
SMC  acquisition  progr  am  and  techrrical  objectives,  as  it  pertains  to  the  implementation  of  EMI/EMC  program 
strategies  and  plans. 
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Applicable  governance,  standards,  and  guidance 

EMI/EMC  is  ail  integral  part  of  several  mandates  including  public  policies,  directives,  and  instructions.  It  is  a 
specialty  engineering  discipline  that  interacts  with  multiple  functional  disciplines  within  the  Systems 
Engineering  realm  including  the  Systems  Engineer.  Survivability  Engineer.  Human  Systems  Integration, 
Spectrum  Manager,  Software  Engineer,  Test  and  Evaluation,  and  others.  Table  21  below  identifies  the 
significant  governance  which  generally  requires  SMC  compliance  for  EMI/EMC.  EMI/EMC  standards 
applicable  to  SMC  procurements,  and  guidance  . 

Table  21  Governauce.  standards,  and  guidance  that  shape  the  EMI/EMC  Discipline 


Document  No 

Governance  Title 

Issue 

NTIA 

Manual  of  Regulations  for  Radio  Frequency  Management 

May  10 

DoDD  3222.3 

DoD  Electromagnetic  Environmental  Effects  (E3)  Program 

08  Sep  04 

DoDD  4630.05 

Interoperability  &  Su portability  of  IT  &  National  Security  Systems 

05  May  04 

DoDI  4650.01 

Policy  For  The  Management  &  Use  of  the  Electromagnetic  Spectrum 

09  Jan  09 

DoDD  5000.01 

The  Defense  Acquisition  System 

12  May  03 

DoDI  4630.8 

Procedures  for  Interoperability  and  Supportability  of  IT  and  NSS 

30  Jun  04 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

DoDI  6055.11 

Protection  of  DoD  Personnel  from  Exposure  to  RF  Radiation  and  Military 
Exempt  Lasers 

19  Aug  09 

CJCSI  6212.01E 

Operation  of  the  Joint  Capabilities  Integration  and  Development  System 

01  May  07 

AF1 10-601 

Interoperability  and  Supportability  of  IT  and  National  Security  Systems 

15  Dec  08 

AF1 10-602 

Operational  Capability  Requirements  Development 

12  JullO 

AFI 63-1201 

Determining  Mission  Capability  &  Supportability  Requirements 

18  Mar  05 

A1 AA-S- 121-2  OOZ 

Life  Cycle  Systems  Engineering 

23  Jul  07 

DOT&E  E3  PM 

Policy  on  OT&E  of  E3  &  Spectrum  Management 

25  Oct  99 

FIPS  PUB  140-2 

Security  Requirements  for  Cryptographic  Modules  (mandated  by  DISR) 

1 1  Jan  94 

Document  No 

Standard  Title 

Issue 

MIL-STD-1542B 

EMC  and  Grounding  Requirements  for  Space  System  Facilities,  USAF 

15  Nov  91 

MIL-STD-1541A 

Electromagnetic  Compatibility  Requirements  for  Space  Systems,  USAF 

30  Dec  87 

MIL-STD464A 

Electromagnetic  EMI/EMC  Effects  Requirements  for  Systems 

19  Dec  02 

MIL-STD461F 

Electromagnetic  Emissions  and  Susceptibility,  Requirements  for  the 

Control  of  Electromagnetic  Interference 

10  Dec  07 

SMC-S-001 

Systems  Engineenng  Requirements  and  Products 

12  July  10 

SMC-S-008 

Electromagnetic  Compatibility  Requirements  For  Space  Equipment  And 
Systems 

13  June  08 

SMC-S-016 

Test  Requirements  for  Launch,  Upper-Stage  and  Space  Vehicles 

13  Jun  08 

SMC-S-021 

Technical  Reviews  &  Audits  for  Systems,  Equipment  and  Computer 

Software 

15  Sep  09 

IEEE  C63.14 

ANS  Dictionary  for  Technologies  of  EMC,  EMP,  &  ESD 

21  Apr  92 

Document  No 

Guidance  Title 

Issue 

CJCSM  3170.01C 

Operation  of  the  Joint  Capabilities  Integration  and  Development  System 

01  May  07 

DAG 

The  Defense  Acquisition  Guidebook 

05  May  10 

MIL-HDBK-235 

Electromagnetic  Environment  Considerations  For  Design  &  Procurement 

Of  Electrical  &  Electronic  Equipment,  Subsystems  And  Systems 

22  Dec  00 

MIL-HDBK-237 

Electromagnetic  EMI/EMC  Effects  and  Spectrum  Certification  Guidance  for 
the  Acquisition  Process,  Department  of  Defense 

20  May  05 

AFI  63-101 

Acquisition  and  Sustainment  Life  Cycle  Management 

22  Mar  11 

The  list  of  data  Item  Descriptions  (DIDs)  provided  below  correlate  with  Mil  STD  461  data  deliverables  for 
EMI/EMC. 
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Date  Item  Title 

Date  Item  Description  (DID) 

Electromagnetic  Interference  Control  Procedures  (EMI CP) 

DI-EMCS-80199C 

Electromagnetic  Interference  Test  Report  (EMITR) 

DI-EMCS-80200C 

Electromagnetic  Interference  Test  Procedures  (EM1TP) 

DI-EMCS-80201C 

Electromagnetic  Compatibility  Program  Procedures 

DI-EMCS-81528 

EMI/EMC  Engineers'  Contributions  to  the  Acquisition  Life  Cycle 
Framework 

Li  general  EMI/EMC  consists  of  the  following  four  main  categories  that  an  EMC  Engineer  (EMCE)  needs  to 
recognize:  (1)  conducted  emissions:  (2)  conducted  susceptibility:  (3)  radiated  emissions:  and  (4)  radiated 
susceptibility.  Below  are  brief  descriptions  of  each  of  the  categories. 

Conducted  emissions.  Refers  to  the  electromagnetic  energy  created  in  an  electronic  device  that  is  coupled  to 
the  device's  power  lines,  antenna  inputs,  or  interconnecting  cables  in  the  system. 

Conducted  susceptibility.  Is  concerned  with  the  ability  of  an  electronic  circuit,  equipment,  subsystem,  or 
system  to  operate  acceptably  when  subjected  to  RE  voltage  or  current  on  interconnecting  conductors. 

Radiated  emissions.  Refers  to  the  unintentional  release  of  electromagnetic  energy  from  an  electronic  device 
that  propagates  away  from  the  device. 

Radiated  susceptibility7.  Is  concerned  with  the  ability  of  an  electronic  circuit  equipment,  subsystem  or  system 
to  operate  acceptably  when  subjected  to  an  externally  generated  electromagnetic  field. 

The  DoD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  EMI/EMC  engineering  contributions  over  this  life 
cycle  are  best  represented  witlrin  the  phase  of  acquisition.  Figure  21  provides  the  acquisition  life  cycle 
framework  within  which  the  EMCE  performs  as  well  as  the  products  that  the  EMCE  develops  or  contributes  to 
their  development. 

The  SMC  Program  Office  establishes  and  implements  EMI/EMC  engineering  program  strategies  and 
objectives  consistent  with  the  tenets  of  appropriate  policies,  SMC  acquisition  objectives,  and  program 
objectives.  The  Program  Office  develops,  attains  approval  for,  and  implements  EMI/EMC  engineering 
planning  into  higher  level  integrated  planning  (e.g.,  SEP,  IMP,  LCMP,  LCSP)  hi  accordance  with  current  DoD 
policy.  Tliis  planning  is  firmly  based  on  program  and  technical  objectives,  strategies,  DoD  mandates,  and 
instructions. 

An  effective  EMI/EMC  program  supports  all  of  the  major  acquisition  activities  through  the  full  system  life 
cycle.  The  planning  sufficiently  defines  the  EMI/EMC  program  to  achieve  the  EMI/EMC  engine errng  and 
overall  program  objectives  and  requirements;  specifies  tasks  and  functions  to  be  performed,  timing  of  tasks, 
resources  requited,  and  products  to  be  developed:  forms  the  basis  for  the  development  of  the  program 
EMI/EMC  engineering  or  Operating  Instruction  (QI)  -  if  required  as  a  critical  process.  The  EMEEMC 
engineering  plaiming  and  QI  are  then  reflected  appropriately  in  the  WBS.  IMS,  and  other  program  documents 
that  address  EMI/EMC  engineering  related  elements.  The  EMI/EMC  engineering  planning  is  executed 
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concurrently  with  the  Program  Office  QI  that  documents  the  process  to  perform,  contra i,  and  integrate  all 
EMI/EMC  engineering  and  management  activities  for  each  phase  of  acquisition.  The  SMC  Program  Office 
EMI/EMC  engineering  plan  and  OI  are  also  based  upon  the  appropriate  program-approved  life  cycle.  The 
following  subsections  delineate  the  EMCE  contributions  to  acquisition  activities  and  products  by  DoD 
acquisition  Phase. 

1.  Materiel  Solution  Analysis*  During  this  phase,  the 
EMCE  provides  inputs  to  and  supports  select  program 
acquisition  activities  to  include  the  development  of  the 
acquisition  strategy  if  applicable,  inputs  to  the  cost 
estimates,  solicitatian/RFP  development  for  Contractor 
studies,  and  proposal  evaluation  activities.  The  EMCE 
may  provide  inputs  to  the  initial  regulatory  spectrum 
supports bility  risk  assessment  (SSRA)  to  identify  and 
re  line  issues  related  to  the  EM  environment.  The  EMCE  contributes  to  the  development  of  the  MSA  Phase 
acquisition  products. 

2.  Technology  Development.  Throughout  the  TD  phase, 
the  EMCE  continues  to  provide  inputs  and  supports  all 
program  acquisition  activities.  The  EMCE  is  actively 
involved  in  contributing  toward  the  development  of  the 
acquisition  strategy  if  EMI/EMC  is  a  risk  component. 

The  EMCE  provides  updates  to  the  cost  model  and 
development  of  the  Cost  .Analysis  Requirements 
Description  (CARD),  solicitatiou/RFP  development  and 
proposal  evaluation  activities.  EMCE  also  identifies  other 
EMI/EMC  related  contract  requirements,  including 
related  tasks,  as  well  as  test  &  demo  requirements  to  meet 
EMI/EMC  engineering  objectives.  Dining  this  phase,  the  EMCE  provides  inputs  to  the  initial  technical 
and  initial  operational  SSRAs  to  identify  EM  interactions  that  require  further  study.  The  EMCE  is  an 
important  contributor  to  the  development  and  refinement  of  the  TD  Phase  acquisition  products. 

3*  Engineering  &  Manufacturing  Development,  As  the 

acquisition  process  becomes  more  refined  and  the 
program  enters  the  EMD  phase,  the  EMCE  A  early 
contributions  to  the  program  become  more  evident  and 
often  influence  the  ultimate  success  of  the  program. 

EMCE  contributions  and  on-going  support  for  all 
program  acquisition  activities  in  the  EMD  phase  may 
remain  a  critical  component  of  the  process.  During  this 
phase,  the  EMCE  provides  input  to  a  detailed  regulatory 
and  a  detailed  technical  SSRA  to  ensure  all  EM  issues 
have  been  identified  and  are  being  mitigated.  Like  the  previous  phase,  the  EMCE  is  responsible  for 
updating  the  acquisition  strategy,  the  cost  model  to  reflect  the  actual  technical  solutions  determined,  as 
well  as  the  CARD.  Additionally,  the  EMCE  also  supports  the  soiicitation'REP  development  and  proposal 


EMD  Phase  —  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS _ 

CARD  update _ 

Inputs  to  DP  Form  1494  (Stage  3  SS  Certification) 

RFP  EMI/EMC  objectives  in  the  S00;  EMI/EMC 
related  tasks  in  PWS,  EMI/EMC  CDRLs:  SMC- 
EMi/EMC  standards  -  tailored _ 

APB:  EMI/EMC  objectives  &  related  concept 
descriptions _ 

Detailed  EMI/EMC  planning,  LCMP;  TEMP  updates 

SSRA 


TD  Phase  —  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS _ 

Inputs  to  LC  Cost  Estimate  Update  /  CARD 
Development _ 

Inputs  to  DP  Form  1494  (Stacie  2  SS  Certification) 

RFP:  EMI/EMC  objectives  in  the  SOO;  EMI/EMC 
related  tasks  in  PWS,  EMI/EMC  CDRLs;  SMC- 
EMI/EMC  standards  -  tailored _ 

APB:  EMI/EMC  objectives  &  related  concept 
descriptions _ 

Detailed  EMI/EMC  planning,  LCMF:  TEMP,  ISP 

SSRA 


MSA  Phase  —  SMC  Acquisition  Products 


Inputs  to  ASPk  TDSr  DMS,  TES _ 

Inputs  to  LC  Cost  Estimate _ 

Inputs  to  DP  Form  1494  (Stage  1  SS  Certification) 

RFP  inputs  (EMI/EMC  requirements;  EMI/EMC 
assessment  requirements.  High  level  EMI/EMC 
assessments  of  concepts _ 

Inputs  to  APB,  CCA _ 

Inputs  to  LCMP,  SSRA 
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evaluation  activities  including  providing  technical  inputs  such  as  technical  requirements,  compliance 
standards,  engineering  activities  including  providing  technical  inputs  such  as  technical  requirements, 
compliance  standards,  engineering  approaches,  incentives,  and  warranty  programs  to  meet  program 
objectives.  The  EMCE  identifies  other  contract  requirements  as  necessaty  to  meet  EMI/EMC  engineering 
objectives,  and  contributes  to  the  development  and  update  of  EMD  Phase  acquisition  products. 

4.  Production  &  Deployment,  Operations  &  Support. 

The  EMCE  provides  inputs  to  and  supports  all  program 
acquisition  activities  to  include  updates  to  the  acquisition 
strategy,  the  cost  model  to  reflect  the  actual  technical 
solutions  determined,  the  CARD,  and  any  final 
regulatory,  technical  and  operational  input  to  the  SSRA 
prior  to  requesting  authorization  to  operate  for  other  than 
testing.  The  EMCE  also  supports  the  solicitation  RFP 
development,  proposal  evaluation  activities,  as  well  as 
identifies  other  contract  requirements:  production  and  field  test  &  demo  requirements:  field  performance 
and  sustainment  analyses  to  meet  EMI/EMC  engineering  objectives. 


P&D  /  O&S  Phase  -  SMC  Acquisition 
Products 


Updates  to  ASP,  TPS,  QMS _ 

Enputs  to  DP  Form  1494  (Stage  4  SS  Certification) 

RFP:  EMI/EMC  objectives  in  the  S00;  EMI/EMC 
related  tasks  in  PWS,  EMI/EMC  CDRLs;  SMC- 
EMI/EMC  standards  -  tailored _ 

Detailed  EMI/EMC  planning  LCMPr  TEMP  updates 

CARD  update _ 

SSRA 
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Figure  21  Acquisition  life  cycle  process  for  SMC  EMC 'EM!  Engineering 
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EMI/EMC  Engineers1  Contributions  to  Engineering  Life  Cycle  Framework 


Relationship  to  the  SE  Organization 

The  EMCE  plans  and  executes  the  essential  EMI/EMC  engineering  and  engineering  management  efforts  in  an 
integrated  and  effective  manner  witlrm  the  context  and  hill  support  of  the  overarching  Systems  Engineering 
function.  The  EMCE  ensur  es  that  then  SED  contributions  are  timely,  adequate,  consistent,  and  compliant.  The 
EMCE  ensures  that  then  engineering  contributions  are  channeled  tluough  the  Systems  Engineering  Analyses 
and  Control  activity. 

Systems  Engineers  manage  the  engineering  process  and  activities  depicted  in  Figure  3  while  die  EMCE 
contributes  to  this  process.  The  EMCE  supports  concept  and  architecture  development  and  analyses;  modeling 
and  simulation  efforts;  tec luio logy  studies  when  potentially  hnpacted  by  EMI/EMC  challenges.  The  EMCE 
also  develops/derives  EMI/EMC  related  requirements  and  supports  the  requirements  analyses  and  allocations 
process.  EMCE  participates  in  teclinical  studies  and  solutions  trades  when  EMI/EMC  engineering  is  a  factor. 
Additional  responsibilities  for  the  EMCE  include  assessing  and  proposing  alternative  mitigating  actions  or 
solutions.  EMCE  also  provides  design  analyses  contributions  to  determine  the  need  for  and  the  adequacy  of 
EMI  mitigation  solutions,  e.g.  packaging  designs,  slii elding,  filtering,  circuitry  designs,  etc.  The  EMCE  works 
closely  with  the  System  Engineers  performing  interface  and  functional  analyses  to  leverage  EMI/EMC 
requirements.  The  EMCE  also  supports  verification  and  validation  planning  and  execution. 

In  performing  the  management  and  control  fimction,  the  Systems  Engineer  effectively  integrates  all 
engineering  functions  through  the  hill  system  life  cycle.  The  EMCE  ensures  EMI/EMC  te cluneal  contribution 
to  the  o vein  11  engineering  advances  and  is  appropriately  applied  through  systematic  control,  collaboration  and 
sharing  across  the  organization.  In  addition,  the  EMI/EMC  products  are  timed  arid  applied  by  the  other 
Specialty  Engineers  to  perform  then  unique  contributions,  and  must  be  provided  to  technical  and  program 
management  for  decision  making. 

Relationship  to  other  SEDs 

The  EMCE  SED  relationship  to  other  SEDs  is  summarized  in  Figure  1.  EMCE  interactions  with  the  other 
engineering  disciplines  are  critical  to  perform  and  integrate  their  engineering  contributions  to  the  system 
development  efforts. 

The  EMCE  must  be  knowledgeable  with  regards  to  EMI  /  energy  emissions  safety  margins  and  the  potential 
criticality  of  the  effects  of  interference  induced  anomalies  on  the  system  and  equipment  in  development. 
Interference  safety  margins  are  classified  hito  the  following  three  categories: 

•  Category  I:  Serious  injury  or  loss  of  life,  damage  to  property,  major  loss  or  delay  of  mission 
capability. 

•  Category  II:  Degradation  of  mission  capability  including  auy  loss  of  autonomous  operational 
capability. 

•  Category  III:  Loss  of  fimetions  not  essential  to  mission. 

Hence.  EMCE  teams  with  the  System  Safety  Engineers  and  Reliability  Engineers  to  perform  system  hazards 
and  failure  analyses  to  determine  items  or  functions  when  performed  or  whose  failure  could  lead  to  a 
hazardous  system  state  or  degraded  system  performance  state. 
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Hie  EMCE  works  closely  with  Human  Systems  Integration  to  design  systems  that  can  be  operated  and 
maintained  by  users;  and  are  habitable  and  safe  with  minimal  EMLEMC  and  occupational  health  hazards. 
When  failure  analyses  and  safety  analyses  results  indicate  potential  hazards  impacts  due  to  EMI  or  hazardous 
energy  emissions,  the  EMCE  assists  to  determine  alternative  technology  or  design  solutions  and  ensure 
attaining  EMLEMC  requirements  through  collaboration  with  T&E  for  verification  through  analyses,  demos, 
and  tests. 


The  EMCE  collaborates  with  the  Survivability  Engineering  in  performing  complementary  EMI  analyses  to 
support  the  survivability/vulnerability  analyses.  The  EMCE  also  works  in  conjunction  with  the  Logistics 
Engineers  performing  maintenance  and  sustainment  analyses  to  identify  and  address  EMLEMC  related  issues 
or  risks.  When  considering  a  system's  capability  to  successfully  operate  with  E3  in  the  EME,  the  EMCE  must 
also  collaborate  with  the  Environmental  Engineer  to  ensure  compliance  with  the  National  Environmental 
Policy  Act  (NEPAL  and  in  particular,  any  Environmental  Impact  Assessments  (EIAs) 


Tools  Selection  and  Use 


The  EMCE  considers  effectiveness  and  efficiencies  gained  by 
selecting  and  using  the  best  choice  of  EMLEMC  Engineering 
tools  considering  the  EMLEMC  tool  requirements. 


Typical  EMLEMC  Engineering 
Functions  Requiring  Tools 


EMC  analyses _ 

EMC  planning _ 

Spectrum  Supportability  Risk  Assessments 


Engineering  Activities  and  Products  over  the  Life  Cycle 

EMC  engineering  involves  the  application  of  sound  EM  principles.  Spectrum  Management  teclmologies  and 
design  solutions  to  ensure  interference -tree  operation,  and  clear  concepts  and  doctrine  that  maximizes 
operational  effectiveness,  hi  recent  times,  the  proliferation  of  worldwide  emitters  utilizing  the  EM  spectrum 
poses  additional  challenges  to  the  military  in  ensuring  mission  success  in  reference  to  EMC. 

From  a  technical  per  spective,  the  EMCE  must  be  involved  very  early  in  the  acquisition  process  to  ensure  that 
the  program's  alternative  systems  concepts  and  eventually  the  preferred  concept  factors  in  implications  of 
EMI.  The  following  subsections  delineate  EMCE  contributions  to  engineering  activities  and  teclmical 
products  byDoD  acquisition  phase. 

1.  Materiel  Solution  Analysis*  During  tills 
phase,  the  EMCE  may  provide  inputs  to  and 
support  the  Capabilities  Based  Assessment 
process  and  the  JCIDS  process  to  support 
the  development  of  the  joint  operating,  joint 
functional,  and  joint  integrating  concepts 
that  ar  e  developed  by  the  operating  or  using 
commands  identify  potential  E3  impacts. 

EMCE  may  also  support  XK  or  Program 
Office  efforts  to  develop  the  enabling  or 
preferred  system  concept.  The  EMCE  may  also  support  the  defiling  or  refining  of  EMLEMC  related 
requirements  to  support  ICD  development  while  providing  inputs  to  the  Stage  1  Spec  tin m  Supportability 


MSA  Phase  -  Technical  Products  Required 


SMC  EMLEMC  Technical 

Products 

Contributions  to  Other 
Organizations  *  Products 

High  level  assessment  proposed 
concepts  &  architectures 

Operational  Concepts;  DoDAF 

CVs,  OVs 

Inputs  &  factors  for  concept,  arch, 
technology  studies,  and  trades 

AoA  Studies 

EMI/EMC  Reqts 

ICD 

Roadmap  and  architectural  inputs 
-  Identification  &  mitigations  of 
potential  EMI 

Stage  1  Spectrum  Supportability 
Certification 
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Certification  request  for  approval.  Additionally,  the  EMCE  contributes  to  the  development  of  the  requit  ed 
MS  A  technical  products. 

2.  Technology  Development.  In  the  TD  phase, 
the  EMCE  continues  to  provide  inputs  to 
and  supports  the  JCIDS  process.  The  EMCE 
also  supports  all  the  engineering  activities 
liighlighted  within  the  box  titled 
Engineering  Acfh  fries  for  System  Segment 
Development  &  Design  Figure  21  to 
commence  system  definition  and 
development.  The  EMCE  develops  and  contributes  to  development  of  the  TD  Phase  technical  products  to 
include  technology  studies,  preferred  concept  development,  tec  lino  logy  studies,  requirements 
development,  as  well  as  SSRA  and  E3  control  requirements  in  the  Government's  Statement  of  Work, 
Performance  Specifications,  and  contract  data  requirements.  EMCE  continues  to  ensure  that  representation 
of  EMI 'EMC  engineer  mg  inputs  are  integrated  into  various  teclmical  documentation  including  the  ISP. 
test  requirements  hi  the  TEMP,  updating  EMI/EMC  inputs  to  the  CDD,  as  well  as  the  Stage  2  DD  Form 
1494  Spectrum  Support  ability  Certification. 

3.  Engineering  &  Manufacturing 
Development.  The  work  involved  in  the 
EMD  phase  is  a  continuation  of  the  work 
horn  the  TD  phase  to  include  updates  to  the 
spectrum  and  E3  control  requirements  and 
ensure  they  are  addressed  hi  the  Capability 
Production  Document  and  flow  to  the 
defined  system  and  allocated  requirements. 

The  EMCE  continues  to  provide  inputs  to 
and  supports  the  JCIDS  process.  EMCE 
supports  all  the  engineering  activities 
liighlighted  within  the  box  titled  Engineering  Activities  for  Detailed  Design  Figure  21  to  commence 
detailed  systems  definition  and  development.  The  EMCE  develops  and  contributes  to  development  of  the 
EMD  Phase  teclmical  products  to  include  technology  maturity  assessments;  EMI  EMC  analyses; 
EMI/EMC  system,  allocated,  and  design  requirements  development;  as  well  as  SSRA  and  broader  E3 
control  requirements  in  the  Government’s  Statement  of  Work.  Performance  Specifications,  and  contract 
data  requirements.  The  EMCE  ensures  process  is  in  place  to  report,  analyze,  and  mitigate  hazards  risk  data 
during  DT&E.  The  EMCE  provides  contributions  to  the  development  of  the  EMD  phase  technical 
products  and,  in  particular,  the  CPD.  TEMP,  as  well  as  in  the  submission  for  a  Stage  3  Spectrum 
Supp orta bill ty  Certification  request. 


EMD  Phase  —  Technical  Products  Required 

SMC  EMI/EMC  Teclmical 

Products 

Contributions  to  Other 
Organizations*  Products 

Inputs  to  arch,  technology  eng 
trades;  ISP;  CVs,  QVs,  SVsr 

SvcVs.  StdVs,  AVs 

Inputs  to  CPD 

Inputs  for  performance  and 
sustainment  analyses 

Inputs  to  operational 
assessments 

Inputs  to  Eng  Change  reviews; 
EMI/EMC  design  requirements 

Stage  3  Spectrum  Supportability 
Certification 

Inputs  to  system  design, 
production,  fielding,  sustain  docs 

TD  Phase  —  Technical  Products  Required 


SMC  EMI/EMC  Teclmical 

Products 

Cnntiibutions  to  Other 
Organizations*  Products 

Assessment  proposed  concepts 
architectures,  technologies 

Operational  Concepts;  DoDAF 

CVs,  OVs 

inputs  &  factors  for  concept,  arch, 
technology  studies,  and  trades 

Inputs  to  CDD,  AoA  Studies 

Dev  &  analyses  of  system  & 
allocated  EMI/EMC  requirements 

Stage  2  DD  Form  1494  Spectrum 
Supportability  Certification 
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4.  Production  <&  Deployment,  Operations  & 

Support*  As  in  the  previous  phases,  the 
EMCE  continues  To  ensure  that  the  design 
and  meets  the  contractual  EMI/EMC 
engineering  requirements  and  that 
manufacturing,  build  and  integration 
activities  do  not  induce  additional  challenges 
and/or  risks.  The  EMCE  may  have  to 
conduct  additional  E3  analysis  if  any  operational  parameters  are  changed.  The  EMCE  ensures  the  program 
appropriately  addresses  EMEEMC  issues  in  accordance  with  SMC  Compliancy  Standard,  SMC-S-00S, 
and  provides  contributions  to  the  development  of  the  P&D  /  C)&S  phase  technical  products,  wliich 
includes  the  submission  for  a  Stage  4  Spectrum  Supportability  Certification  request. 

EMI/EMC  Engineers'  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  their  business  model  and  approach  based  primarily  on  program  objectives, 
technical  challenges,  organizational  structure,  and  required  engineering  planning  including  EMI/EMC 
engineering  for  cost-effective  execution. 

EMI/EMC  control  is  a  specialized  fimction  and  must  be  assessed  and  demonstrated  at  the  early  stages  of  initial 
system  concept  development  and  throughout  the  systems  life  cycle.  .An  Electromagnetic  Control  Plan  is 
essential  to  a  properly  conceived  system" s  EMC  performance.  The  initial  Electromagnetic  Control  Plan 
introduces  the  purpose,  scope,  application,  update  and  revision,  and  applicable  reference  documents. 
Additionally,  it  flames  the  plans  purpose,  the  progr  am  outline,  organization,  tasks,  schedule  and  EMC  analysis 
support.  It  provides  a  means  for  interference  control  approach,  while  addressing  EMC  criteria  and  techniques 
with  electrical  bonding  criteria,  electrostatic  grounding  requirements,  grounding  criteria,  wiring,  safety  criteria, 
lightning  protection  criteria,  circuit  design  criteria,  and  mechanical  design. 

In  addition,  an  initial  Electromagnetic  Test  Plan  is  developed.  The  Test  Plan  defines  the  items  to  be  tested, 
procedures,  methods  and  techniques  to  be  used,  resources  required  and  tune  line  definition  compatible  with  the 
Program  Office  Integrated  Master  Schedule  (IMS),  TEMP  and  other”  program  documents 
The  EMCE  develops  and  implements  the  EMI/EMC  engineering  program  planning  to  achieve  Pr  ogram  Office 
EMI/EMC  engineering  objectives  and  requirements.  The  planning  defines  the  EMI/EMC  tasks  and  fiuictions  to 
be  performed  and  products  to  be  developed;  timing  of  tasks,  task  outputs,  resources  (skills,  tools,  equipment, 
and  completion  criteria).  The  EMCE  plans  tasks  to  integrate  EMI/EMC  activities  within  the  Program  Office, 
between  Contractors  and  stakeholders. 

Execution  of  the  EMCE  planning  is  typically  defined  through  an  Operating  Instruction  wliich  implements 
SMC  and  higher  level  instructions,  policies,  and  directives.  The  EMCE  provides  foil  support  to  define  the 
program  and  technical  objectives  where  EMI/EMC  challenges  and  risks  are  known  or  anticipated.  The  EMCE 
assists  to  establish  the  business  model,  develop  program  planning  and  schedules,  and  define  and  implement 
program  processes.  The  EMCE  ensures  the  EMI/EMC  components  of  the  program  are  appropriately 
represented  in  the  program  plans,  program  schedules,  work  breakdown  schedules,  and  cost  estimates.  The 
EMCE  also  reports  their  technical  performance  and  progress,  and  shares  in  the  risk  management 


P&D  /  O&S  Phase  -  Technical  Products  Required 


SMC  EMI/EMC  Technical 

Products 

Contributions  to  Other 
Organizations  *  Products 

Inputs  tech  baseline  engineering 
changes 

Supportability  assessment  Rpt 

Inputs  to  Testr  Demo  docs 

Operational  assessments 

contnbutions 

Inputs  to  Transition  &  Fielding 
Docs 

Stage  4  Spectrum  Supportability 
Certification 
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responsibilities  to  identify,  assess,  and  propose  mitigating  actions  of  EMI/EMC  related  risks.  Tliey  also  support 
the  program  manager's  problem  identification,  resolution,  and  decision-making  processes. 

Hie  EMCE  supports  the  PMs  in  developing  spectrum-dependent  (S-D)  systems/equipment  to  consider 
spectrum  requirements  and  Electromagnetic  Environmental  Effects  control  early  in  the  development  process  to 
ensure  equipment  can  operate  compatibly  with  other  S-D 
equipment  already  in  the  intended  operational  environment 
The  EMCE  contributes  to  the  development  of  the  program 
management  products  identified  in  the  Table. 


SMC  Program  Management  Product' 


PMD _ 

jMPJNjSJVBS  _ _ _ _ 

Technical  progression  and  issues  reporting 

LC  Cost  Estimate  (CARDs) _ 

Processes  (OEs) _ 

Risk  Management  inputs  (SSRA) 


PMP 
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Appendix  Q  -  Parts  Materials,  and  Processes  Engineering 

Parts,  Materials,  and  Processes  (PMP)  engineering  is  a  well-defined  SMC  discipline.  PMP  activities  are 
performed  over  the  lifecycle  of  a  system.  During  concept  and  technology  development,  PMP  is  an  integral 
engineering  consideration  to  identify  and  mitigate  PMP  related  risks  and  perform  tradeoffs  between  system 
performance,  technology  advancements,  PMP  reliability!  availability,  prodncibility  and  ease  of  maintenance, 
and  cost.  During  system  development  and  design.  PMP  Engineers  ensure  all  activities  and  processes  are 
adequate  for  the  application,  selection,  qualification,  procurement,  documentation  and  disposition  of  all  parts, 
materials  and  processes  required  to  hup  lenient  the  system  design.  This  includes  all  flight,  qualification,  proto- 
qualification.  and  deliverable  ground  segment  hardware. 


PMP  engineering  involves  three  engineering  disciplines:  Parts  /  Components  Engineers,  Materials  and 
Processes  Engineers,  and  Contamination  Control  Engineers.  A  typical  PMP  program  (SMC  and  Contractor 
participation)  is  depicted  in  Figure  22  below. 


Parts  Control  Plan 
MSPAR  Approval 
PMPSl 

SCD,  SMD  Development 
Critical  &  Long  Lead  Parts  List 
RH  A  Testing  fQual 
Gidep  Alerts 

Parts  Databases  Management 

Supplier  /  Vendor  Selection,  Control,  Audits 

Government  Technology  Programs  Interactions 


PMP  Control  Plan 
Mew  M&P  Development 
PMPSL 

Critical  &  Long  Lead  M&P  List 
M&P  Specifications  /  Procedures 
Material  Reviews 
Gidep  Alerts 

M&P  Databases  Management 
M&P  Vendor  Selection ;  Control,  Audits 


Contamination  Control  Plan 

Satellite  Contamination  Modeling  &  Budget  Allocation 

Satellite  Contamination  Analysis 

Contamination  Monitoring  &  Prevention  Procedures 

Contamination  Cleanings  inspection  Procedures 

Facilities  Contamination  Requirements 

Audits  &  Reviews 

TQCM  Data  Analysis 

Training  and  Certification 

Launch  Site  Integration 

Contamination  Control  Meetings 


Figure  22  Typical  Parts,  Materials,  aiid  Processes  Program 


Instructions,  guidance,  aud  senior  expert  SMC  Staff  resources  are  available  to  assist  the  Program  Office  PMP 
Engineer  stand-up  and  execute  the  essential  PMP  engineering  activities  for  the  Program  Office.  Much  of  the 
PMP  Engineers'  activities  include  implementation  of  the  PMP  Selection  and  Control  program.  A  parts, 
materials,  and  processes  selection  and  control  program  is  vital  to: 


•  Ensure  integrated  management  and  balanced  technical  decisions  regarding  selection,  application, 
acquisition,  control,  and  standardization  of  parts,  materials,  and  processes 

•  Improve  acquisition  and  qualification  of  piece  parts,  materials,  and  critical  processes  that  meet  system 
requirements 

•  Implement  the  reliability  program  at  the  PMP  level  to  reduce  PMP  failures  at  all  levels  of  integration, 
assembly,  test,  and  operations 

•  Reduce  program  life-cycle  costs 
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PMP  is  accomplished  by  a  team  of  PMP  Engineers,  Systems  Engineers,  Quality  Engineers,  Reliability 
Engineers,  Design  Engineers.  Test  Engineers,  and  others  that  understand  their  responsibilities  to  collaborate  to 
achieve  the  PMP  objectives  and  requirements.  The  Till  intent  is  to  address  PMP  related  lisks  as  early  as 
possible  in  the  product  lifecycle  to  provide  greater  opportunities  to  make  balanced  decisions  regarding  PMP 
selections.  As  design  decisions  are  made  and  the  development  efforts  transition  to  production  and  fielding, 
PMP  related  design  changes  may  be  orders  of  magnitude  more  expensive.  An  effective  PMP  program  seeks  to 
minimize  the  use  of  nonstandard  parts,  hazardous  materials,  and  critical  processes  with  the  end  result  of 
minimizing  total  life-cycle  costs.  The  PMP  Engineer  conducts  or  oversees  the  selection  process  factoring 
system  reh ability,  manufacturing  quality  controls,  operational  environments,  and  parts  obsolescence 
mitigations  due  to  Diminishing  Manufacturing  Sources  and  Material  Shortages  (DMSMS). 

The  PMP  Engineer  plans  and  executes  the  essential  PMP  Engineering  and  management  efforts  in  an  integrated 
and  effective  maimer  to  ensure  that  each  PMP  contribution  is  timely,  adequate,  consistent,  and  compliant.  The 
PMP  Engineer  ensures  that  then  engineering  contributions  are  also  channeled  through  the  Systems  Engineering 
Analyses  and  Control  activity. 

Applicable  governance,  standards,  and  guidance 

Policy,  directives,  and  instructions  that  mandate  SMC  PMP  engineering  related  program  requirements  are 
included  in  a  wide  range  of  mandates  including  those  providing  requirements  for  acquisition.  Systems 
Engineering,  Reh  ability,  T&E,  Quality  Assurance,  and  others. 

The  DoDI  5000.02  directs  the  establishment  of  a  viable  reliability  strategy  and  growth  progr  am  as  an  integr  al 
part  of  design  and  development.  System  reliability  is  achieved,  in  part,  through  rigorous  parts  design  practices, 
selection,  qualification,  and  process  control  to  optimize  yield  and  minimize  workmanship  issues.  DoDI 
5000.02  and  DoDI  5000.67  also  require  a  long-term  DoD  corrosion  prevention  and  control  strategy  that 
supports  reduction  of  total  cost  of  system  ownership.  AC  AT  I  programs  document  its  strategy  in  a  Corrosion 
Prevention  Control  Plan.  The  Plan  is  required  at  Milestones  B  and  C.  Cocos  ion  assessments  are  performed 
tluoughout  program  design  and  development  activities  with  trades  made  through  a  transparent  assessment  of 
alternatives. 

ATI  63-1201  requires  the  use  of  Program  Office  approved  parts  only  in  the  system.  Hence  the  Program  Office 
must  be  an  integral  participant  and  approval  authority  for  the  system  parts  selection  process.  The  SMC  Systems 
Engineering  Standard  SMC-S-001  also  provides  requirements  for  the  PMP  Engineer: 

•  Detailed  environmental  parameters  are  defined/derived  that  impact  parts  performance. 

•  Parts /mate rials  engineering/design  requirements  are  allocated,  baselined,  and  traceable  to  system  level 
performance  requirements,  including  risk  assessments. 

•  Functional  parts  parameters  are  baselined  and  captured  in  detailed  technic al/procureinent 
specifications,  e.g..  Specification  Control  Drawings  (SCDs),  Standard  Microcircuit  Drawings 
(SMDs).  [Feb  13,  2011,  John  IC's  comment:  At  the  top  of  page  217  there  is  a  bullet  -  Functional 
Parts  Parameters  etc  this  needs  to  be  deleted  and  rewritten. SMC -S-009  /010  designate  the  Space 
Qualified  Baseline  for  parts  Active  and  Passive  and  materials  ,  there  are  detailed  rules  for  Parts  and 
Material  selection.  Use  of  SCDs  and/or  SMDs  is  a  last  resort.  Reference  to  Parts  engineers  should 
include  Contractors  Parts  Engineers.] 


PMP 
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•  Technology  development  plans  are  executed  and  technology  readiness  levels  demonstrate 
prodncts/technology  suitable  for  system  application  and  support  program  development  schedules. 

•  Qualified  sources  of  supply  and  industrial  base  assessment  results  are  addressed. 

•  Space  systems  radiation  hardening  design  solutions  are  established . 


The  SMC  PMP  standards  SMC-S-009  through  -Oil  provide  the  detailed  Contractors'  PMP  program 
requirements.  These  standards  are  intended  to  be  appropriately  tailored  and  placed  on  SMC  development 
contracts  for  Contractor  compliance.  Table  22  below  identifies  the  significant  governance,  standards,  and 
guidance  winch  generally  require  SMC  compliance  for  PMP  Engineering. 

Table  22  Governance,  standards,  and  guidance  that  shape  the  Parts  Materials,  and  Processes  Engineering  discipline 


Document  No 

Gover  nance  Title 

Issue 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

CJCSM  3170.01 

Operation  of  the  Joint  Capabilities  Integration  and  Development  System 

24  Jun  03 

DoDI  5000.67 

Prevention  &  Mitigation  of  Corrosion  on  DoD  Military  Equipment  and 
Infrastructure 

25  Jan  08 

DoDI  4140  57 

DoD  Replenishment  Parts  Purchase  or  Borrow  (DoD  RPPOB)  Program 

30  May  08 

Document  No 

Standards  Title 

Issue 

ASTME  1548-2009 

Standard  Practice  for  Preparation  of  Aerospace  Contamination  Control 
Plans 

2006 

ANSI/AIM  R-100A-2001 

Recommended  Practice  for  Parts  Management 

2001 

SMC-S-001 

Systems  Engineering  Requirements  and  Products 

12  July  10 

SMC-S-009 

PMP  Control  Program  for  Space  and  Launch  Vehicles 

12  Jan  09 

SMC-S-010 

Technical  Requirements  for  Electronic  Parts,  Materials,  and  Processes 

For  Space  and  Launch  Vehicles 

12  Jan  09 

SMC-S-01 1 

PMP  Control  Program  for  Expendable  Launch  Vehicles 

13  Jun  08 

Document  No 

Guidance  Title 

Issue 

MIL-HDBK-512 

Parts  Management  Flandbook 

TOR-2006(8583)-5235 

PMP  Control  Program  for  Space  and  Launch  Vehicles 

Nov  06 

CPATS 

Critical  Process  Assessment  Tool  -  PMP 

23  Sep  06 

SD-19 

Parts  Management  Guide 

Sep  09 

PMP  Engineers'  Contributions  to  the  Acquisition  Life  Cycle  Framework 

The  DoD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  PMP  Engineering  contributions  over  this  life  cycle 
ar  e  best  represented  within  the  phase  of  acquisition. 

Figure  23  provides  the  acquisition  life  cycle  framework  within  which  PMP  Engineers  perform  as  well  as  the 
products  tliat  the  PMP  Engineers  develop  or  contribute  to  their  development.  This  figure  along  with  SMCI  62- 
1201,  provide  the  requirements  to  perform  PMP  engineering  planning,  support  pre  and  post  contract  award 
acquisition  activities,  and  perform  PMP  engineering  and  management  across  the  system  lifecycle.  SMC 
Program  Offices  establish  and  implement  PMP  Engineering  program  strategies  and  objectives  consistent  with 
the  tenets  of  applicable  policies.  SMC  acquisition  objectives,  and  program  objectives.  The  Program  Office 
develops,  attains  approval  for,  and  implements  PMP  Engineering  (parts  and  materials  selection  Sc  control, 
process  development  Sc  control.  Corrosion  prevention)  planning  into  the  Systems  Engineering  Plan  (SEP)  and 
higher  level  integrated  planning  (e.g.,  IMP)  hi  accordance  with  current  DoD  policy.  This  planning  is  firmly 
based  on  program  and  technical  objectives,  strategies,  DoD  mandates,  and  instructions.  The  planning 
sufficiently  defines  the  PMP  program  to  achieve  the  PMP  engineering  and  overall  program  objectives  and 
requirements;  specifies  tasks  and  functions  to  be  performed,  timing  of  tasks,  resources  required,  and  products 
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to  be  developed:  forms  the  basis  for  the  development  of  the  program  PMP  engineering  Instruction  (01).  The 
PMP  OI  may  be  contained  within  the  SE  OI. 


The  PMP  engineering  planning  and  OI  are  then  reflected  appropriately  in  the  WBS,  IMS.  and  other  program 
documents  that  address  PMP  engineering  related  elements.  The  SMC  Program  Office  System  PMP  planning 
(usually  contained  in  the  SEP  and  the  detailed  PMP  engineering  program  planning)  and  OI  are  also  based  upon 
the  appropriate  program-approved  life  cycle.  The  following  subsections  delineate  PMP  engineering 
contributions  to  acquisition  activities  and  products  by  DOD  acquisition  Phase.  Refer  to  ASTM  E  1548-2009. 
Standard  Practice  for  Preparation  of  Aerospace  Contamination  Control  Plans  and  ANSI/AIAA  R-100A-2001, 
Recommended  Practice  for  Parts  Management  for  a  more  complete  list  of  PMP  Engineering  activities  and 
products  that  are  prepared  by  the  Program  office  and  their  Contractors. 


1*  Materiel  Solution  Analysis.  During  this  phase  the  PMP 
Engineer  provides  inputs  to  and  supports  most  program 
acquisition  activities  to  include  the  development  of  the 
acquisition  strategy,  inputs  to  the  cost  estimates, 
solicitation/RFP  development  for  Contractor  studies,  and 
proposal  evaluation  activities.  The  PMP  Engineer  also 
contributes  to  the  development  of  the  MSA  Phase 
acquisition  products. 


MSA  Phase  -  SMC  Acquisition  Products 


PMP _ 

ASP,  TDS:  DMS,  TES 

LC  Cost  Esti  mate _ 

RFP  inputs  (PMP  related  constraints  and  requirements; 
High  level  assessments  of  concepts _ 

APB,  CCA _ 

SEP.  LCMP,  ISP 


2. 


Technology  Development.  The  PMP  Engineer  provides 


TD  Phase  -  SMC  Acquisition  Products 


inputs  to  and  supports  all  program  acquisition  activities  to 
include  the  development  of  the  acquisition  strategy, 
updates  to  the  cost  model  and  development  of  the  Cost 
Analysis  Requirements  Description  (CARD), 
solicitation/RTP  development  and  proposal  evaluation 
activities.  The  PMP  Engineer  identifies  other  related 
contract  requirements  for  PMP  selection,  control,  and 
qualification*  Long  Lead  (LL)  purchases  to  meet  PMP 
Engineering  objectives  and  required  SMC  PMP  requirements.  The  PMP  Engineer  also  contributes  to  the 


Updates  to  ASP,  TPS,  DMS _ 

LG  Cost  Estimate  Update  /  CARD  Development _ 

RFP:  PMP  objectives  in  the  S00;  PMP  related  tasks  in 
SOW,  PMP  data  products  in  CDRLs;  SMC-  PMP 
standards  -  tailored _ 

APB:  PMP  objectives  &  related  concept  descriptions 
Detailed  PMP  and  corrosion  prevention  planning; 
Inputs  to  SEP;  LCMP,  TEMP _ 

Initial  PM  SDL,  Critical  Materials  and  Processes  Lists 


dev  elopment  and  updates  to  the  TD  Phase  acquisition  products. 


EMD  Phase  -  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS 


CARD  Update 


RFP:  PMP  objectives  in  the  S00;  PMP  related  tasks  in 
SOW,  PMP  data  products  in  CDRLs;  SMC-  PMP 
standards  -  tailored 


3.  Engineering  &  Manufacturing  Development.  The  PMP 
Engineer  provides  inputs  to  and  supports  all  program 
acquisition  activities  to  include  updates  to  the  acquisition 
strategy  and  updates  to  the  cost  model  to  reflect  the  actual 
technical  solutions  determined  and  updates  to  the  CARD 
PMP  Engineer  supports  the  solicitation/REP  development 
and  proposal  evaluation  activities  which  include 
providing  the  technical  inputs  including  technical 
requirements.  compliance  standards,  engineering 
approaches,  incentives,  and  warranty  programs  to  meet  program  objectives.  The  PMP  Engineer  identifies 
other  related  contract  requirements  for  PMP  selection,  control,  and  qualification,  parts  and  materials 
purchases,  parts  obsolescence  avoidance,  sparing,  etc.  to  meet  PMP  engineering  objectives  and  required 


Detailed  PMP  and  corrosion  prevention  planning. 
Inputs  to  SEP,  LCMFrTEMP 


PMSDL.  Critical  Materials  and  Processes  Lists 
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SMC  PMP  requirements  per  the  standards  cited  in  the  standards  table  above.  PMP  Engineer  also 
contributes  to  the  development  and  updates  to  the  EMD  Phase  acquisition  products. 

4,  Production  &  Deployment,  Operations  &  Support. 

The  PMP  Engineer  provides  inputs  to  and  supports  all 
program  acquisition  activities  to  include  updates  to  the 
acquisition  strategy  and  updates  to  the  cost  model  to 
reflect  the  actual  technical  solutions  determined  and 
updates  to  the  CARD.  The  PMP  Engineer  supports  the 
solicitation/RFP  development  and  proposal  evaluation 
activities. 

The  PMP  Engineer  identifies  other  related  contract  requirements  for  PMP  selection;  control:  qualification; 
pails  and  materials  purchases;  paits  obsolescence  avoidance:  manufacturing  controls,  inspections,  testing: 
sparing,  etc.  to  meet  PMP  engineering  objectives  and  required  SMC  PMP  requirements  per  the  standards 
cited  in  the  standards  table  above.  The  PMP  Engineer  identifies  other  contract  requirements  for  field  test 
Sc  demo  requirements;  field  performance  and  sustainment  analyses. 


P&D  /  O&S  Phase  SMC  Acquisition 
Products 


Updates  to  ASP,  TPS,  DMS _ 

RFP:  PMP  objectives  in  the  S00;  PMP  related  tasks  in 
SOW,  PMP  data  products  in  CDRLs;  SMC-  PMP 
standards  -  tailored _ 

APB:  PMP  objectives  &  related  concept  descriptions 

Detailed  PMP  and  corrosion  prevention  planning; 
Inputs  to  SEP.  LCMP.TEMP _ 

CARD  update _ 
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Figure  23  Acquisition  life  cycle  process  for  SMC  Parts,  Materials,  anti  Processes 
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PMP  Engineers'  Contributions  to  the  Engineering  Life  Cycle  Framework 

Relationship  to  the  SE  Organization 

The  PMP  Engineer  plans  and  executes  the  essential  PMP  engineering  and  engineering  management  efforts  in 
an  integrated  and  effective  manner  within  the  context  and  full  support  of  the  overarching  Systems  Engineering 
fmiction.  The  PMP  Engineer  ensures  that  their  SED  contributions  are  timely,  adequate,  consistent,  and 
compliant.  The  PMP  Engineer  ensures  that  their  contributions  are  channeled  through  the  Systems  Engineering 
Analyses  and  Control  activity. 

Systems  Engineers  manage  the  engineering  process  and  activities  depicted  in  Figure  3  while  the  PMP  Engineer 
contributes  to  this  process.  PMP  Engineers  support  concept  and  architecture  development  and  analyses: 
modeling  and  simulation  efforts:  technology  studies  when  potentially  impacted  environmental  challenges.  The 
PMP  Engineers  develop/derive  the  PMP  related  requirements  and  support  the  requirements  analyses  and 
allocations  process.  They  also  participate  hi  technical  studies  and  technical  solutions  trades  when  PMP  is 
potentially  impacted.  They  provide  design  analyses  contributions  to  determine  DMSMS  /  parts  obsolescence 
issues:  parts  performance,  reliability,  prod  liability,  and  quality  assurance  concerns,  and  other  potential  risks  or 
concerns  that  impact  PMP.  They  assess  and  propose  alternative  mitigating  actions  or  solutions.  The  PMP 
Engineer  also  works  closely  with  the  System  Engineers  performing  technology  studies  and  assessments, 
requirements  analysis,  reliability  and  hazards  analysis,  benign  and  hostile  environments  analysis.  The  PMP 
Engineer  also  supports  the  integration  and  verification  and  validation  planning  and  execution. 

In  performing  the  management  and  control  fimction,  the  Systems  Engineer  effectively  integrates  ail 
engineering  functions  tluough  the  full  system  life  cycle.  The  PMP  Engineer  ensures  their  technical  contribution 
to  the  overall  engineering  advances  and  is  appropriately  applied  through  systematic  control,  collaboration  and 
sharing  across  the  organization.  For  example,  their  activities  and  products  are  timed  to  coincide  with 
architectural  trades,  design  trades,  reliability  analyses.  In  addition  the  Environmental  products  are  timed  and 
applied  by  the  other  Specialty  Engineers  to  perform  their  unique  contributions,  and  must  be  provided  to 
technical  and  program  management  for  decision  making.  The  PMP  Engineer  oversees  The  Contractors'  PMP 
selection  and  control  process. 

Relationship  to  other  SEDs 

The  PMP  Engineer  SED  relationship  to  other  SEDs  is  summarized  in  Figure  1 .  PMP  Engineer  interactions  with 
the  other  SEDs  are  critical  to  perform  and  integrate  then  engineering  contributions  to  the  system  development 
efforts. 

PMP  Engineers  team  with  the  Reliability  Engineers  to  perform  analyses  to  determine  reliability  allocations  to 
the  piece  part  level,  piece  part  yields,  material  life  limitations  material  hazards,  and  parts  qualification  testing 
requirements.  When  failure  analyses  results  indicate  the  need  to  reallocate  reliability  parameters  at  the  parts 
level,  the  PMP  Engineer  assists  to  adjust  reliability  allocations  and  ensure  confidence  hi  attaining  system  level 
requirements  through  analyses,  demo,  and  test. 

PMP  Engineers  team  with  Quality  Assurance  and  Quality  Engineers  to  determine  component  manufacturing 
controls  to  maintain  quality  conformance  levels,  establish  acceptable  yield  rates,  and  minimize  rework  and 
repairs. 
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Hie  PMP  Engineer  works  closely  with  the  Logistics  Engineers  defining  the  maintenance  concept,  and 
performing  maintenance  and  sustainment  analyses  to  identify  and  address  sparing  needs  and  requirements. 

Tools  Selection  and  Use 

The  PMP  Engineer  considers  effectiveness  and  efficiencies 
gained  by  selecting  and  using  the  best  choice  of  PMP 
engineering  tools  considering  the  PMP  tool  requirements 
possibly  for  hazards  analyses,  information  sharing,  automated 
data  exchanges  with  other  tools,  and  other  considerations. 

Engineering  Activities  and  Products  over  the  Life  Cycle 

Design  engineering  of  our  space  assets  depends  on  the  criticality,  type,  and  application  of  the  system  being 
acquired  by  SMC.  Paris  and  material  design  and  selections  for  space  vehicle  and  launch  vehicle  require  unique 
qualifications  for  launch  and  space  environments.  Transporting,  deploying,  and  operating  in  space  requires 
liighly  robust  piece  parts.  Piece  parts  /  components  must  be  designed  to  perform  in  extreme  hot  and  cold 
temperatures  and  harsh  space  environments  that  include  energetic  particle  radiation,  plasmas,  micro ■ -particles, 
and  contamination.  Hence,  piece  parts  /  components  undergo  environmental  testing  requires  highly  specialized 
facilities  and  equipment  to  simulate  the  severe  launch  and  operational  environments  of  space.  Parts  and 
material  design  and  selections  for  our  ground  systems  take  into  account  field  deployable  and  located  and 
operated  in  any  terrain  and  climate  conditions  and  are  usually  air  and  ground  transportable  or  placed  in  a  more 
benign  permanently  fixed  site. 

As  a  result,  a  comprehensive  PMP  program  is  required  to  avoid  risks  associated  with  PMP  development, 
design,  selection,  and  control.  The  contractor  is  usually  required  to  prepare  and  submit  a  PMP  Program  Plan  to 
the  Program  Office  with  then  proposal  or  shortly  following  contract  award .  The  plan  defines  the  overall  scope 
and  activities  required  in  order  to  accomplish  the  technical,  schedule  and  cost  requirements  defined  in  the 
contract.  The  activities  in  the  PMP  Program  plan  include  hut  are  not  limited  to: 

•  Roles,  responsibilities  and  interfaces  with  other  program  and  functional  organizations 

•  Requirements  derivation  and  flow- down 

•  Paris  and  materials  selection,  analysis  (design  margin,  derating,  stress  analysis,  etc.),  documentation, 
procurement  and  qualification 

•  New  technology  insertion  and  qualification 

•  Engineering  drawing  review  and  signoff 

•  As-Designed  and  As-Built  PMP  Lists 

•  PMP  Risk  Management 

•  Subcontractor  and  Supplier  selection,  qualification  and  monitoring 

•  PMP  Lo  t  Tr a  c  e  a  bi  li  ty  and  C ontrol 

•  PMP  inspection,  handling,  ESD  control,  shelf  life  control,  and  re -qualification 

•  Discrepant  PMP  disposition  and  tracking 

•  Destructive  Physical  analysis 


Typical  PMP  Engineering  Functions 
Requiring  Tools 


PMP5L  Management _ 

SCD,  SIV1D  development  coordination  and  approval 

Pre-selection  parts  &  materials  database _ 

Analytical  tasks 
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•  Corrosion  Prevention  and  Control 

•  Contamination  Prevention  and  Control 

•  Radiation  Hardness  Assurance  and  Space  Environmental  Analysis,  Qualification  Testing  and  Lot 
Acceptance  Testing 

•  GIDEP  participation 


The  PMP  Engineering  Group  (depicted  in  Figure  22  above)  typically  includes  the  Program  Office  PMP 
Engineer,  Contractor(s)  PMP  Leads,  and  subject  matter  representation.  The  PMP  Engineering  Group  is 
chartered  to  implement  and  operate  the  Parts,  Materials  and  Processes  Control  Board  (PMPCB).  The  purpose 
of  the  PMPCB  is  to  perform  PMP  selection:  define  specification,  qualification,  and  procurement  requirements: 
review,  maintain  and  track  changes  to  the  Paits,  Materials  and  Processes  Selection  List  (PMPSL);  disposition 
discrepant  or  suspect  PMP:  and  assess,  identify,  mitigate,  track  and  report  on  PMP  risks  for  the  entire  program 
The  PMP  representative  from  the  program  office  is  a  member  of  the  PMPCB  and  an  active  participant. 

The  PMPCB  coordinates  all  PMP  across  all  program  organizations  (both  internal  to  the  contractor  and  their 
subcontractors,  suppliers  and  vendors).  The  PMPCB  is  designed  to  provide  both  horizontal  and  vertical  lines 
of  communications  by  allowing  the  participants  to  identify  concerns,  issues  and  problem  areas,  quickly 
determining  their  impact  and  informing  others  within  the  program  organization  including  the  program  office. 
Also,  lessons -learned  for  one  organization  can  be  applied  to  other  organizations  to  reduce  overall  development 
time  and  reduce  acquisition  costs.  With  new  technologies  and  high  product  obsolescence  as  well  as  emphasis 
on  process  validation  as  well  as  product  test  and  qualification,  it  is  very  important  that  past  experiences  and 
lessons -learned  are  taken  in  consideration. 

Consideration  is  also  given  to  the  consequences  resulting  from  inappropriate  requirements  translation  and 
implementation: 

•  Requirements  that  have  been  inappropriately  specified  for  the  teclmology  selected.  During  the  process 
of  vendor  selection,  contractors  may  receive  a  wide  range  of  exceptions  that  might  ultimately  result  in 
either  cost  and/or  schedule  delays  due  either  to  inability  to  manufacture  an  item  or  high  yield  loss 
impacts.  In  addition,  the  probability  of  high  rate  re-work  during  the  manufacturing  phase  due  to 
system  level  failures  that  develop  could  add  additional  costs  and  schedule  delays  to  a  program.  If  the 
requirements  are  not  completely  understood  or  improperly  implemented,  effective  corrective  action 
and  proper  risk  mitigation  cannot  be  performed. 

•  Requirements  have  been  under  stood  and  correctly  specified  but  the  vendor  verification  process  has 
not  been  properly  c allied  out.  Tliis  situation  puts  the  parts  and/or  materials  stocked  lor  the  program  hi 
jeopardy  and  raises  the  probability  of  high  rate  re-work  occurring  dining  the  manufacturing  phase  due 
to  system  level  failures  causing  additional  costs  and  schedule  delays  to  the  program.  If  the 
requirements  have  been  understood  and  specified,  it  is  easier  to  specify  and  cany  out  corrective 
action;  however,  the  program  may  incur  significant  cost  and  schedule  impacts. 

A  typical  example  is  the  present  European  Union  Legislation  and  Regulation  mandate  to  have  electronic 
manufacturers  “lead- free1'  by  July  1,  2006,  To  be  compliant  with  the  European  Union's  prohibition  of  lead 
(and  five  other  substances),  electronics  manufacturers  are  considering  other  materials  that  might  meet 
stipulated  solderability  requirements.  One  such  material  commonly  used  today  is  pure  tin.  Tliis  is  an  excellent 
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choice  in  most  instances  but  in  the  case  of  space  applications  it  is  not  an  acceptable  choice.  Within  the 
environment  of  space,  pure  tin,  pore  zinc,  and  pine  lead  are  known  to  experience  metallic  growths  that  both 
look  like  and  are  called  ""whiskers'7.  The  growths  of  these  metallic  whiskers  have  in  previous  space  systems 
caused  short  circuits  within  the  delicate  electronic  assemblies. 

PMP's  implementation  and  integration  within  the  other  specialty  disciplines  varies  consistent  with  contractor's 
organizational  structure  and  each  program  phase.  The  actual  integration  and  requirements  decomposition 
process  for  each  physical  element  within  each  program  phase  forms  the  contractor’s  proposed  systemic 
approach  to  implementation  of  Mission-need  PMP  Program  Requirements. 

An  effective  PMP  Program  typically  defines  two  levels  of  implementation  and  performance.  The  first  level 
constitutes  the  contractor's  internal  PMP  Process  activities.  The  second  level  constitutes  the  contractor's 
proposed  control  and  flow-down  of  PMP  requirements  to  their  outside  suppliers  or  subcontractors  and 
activities,  to  ensure  uniform  PMP  Progr  am  implementation. 

For  space  programs,  an  Integrated  Pro  gram  Team  or  the  Parts.  Materials,  and  Processes  Board  (PMPCB)  are 
traditionally  established  as  the  vehicle  for  PMP  process  integration  and  interface  with  all  necessary  disciplines 
and  control  of  outside  vendors  and  subcontractors  throughout  all  program  phases. 

The  following  subsections  delineate  the  PMP  Engineer's  contributions  to  the  engineering  activities  and 
products  by  DOD  acquisition  Phase.  Refer  to  ASTM  E  1548-2009,  Standard  Practice  for  Preparation  of 
Aero  sp  a  ce  Contaminati on  Control  Plans  and  AN  SI/AI AA  R- 1 0  0 A-2 00 1 .  Rec  ommended  Pr a  ctic  e  for 

Parts  Management  for  a  more  complete  list  of  PMP  Engineering  activities  and  products  that  are  prepared  by 
the  Program  office  and  their  Contractors, 

1.  Materiel  Solution  Analysis*  During  this 
phase  the  PMP  Engineer  may  provide  inputs 
to  and  support  the  Capabilities  Based 
Assessment  process  and  the  JCIDS  process. 

The  PMP  Engineer  evaluates  proposed 
concepts  and  architectures  to  identify  and 
assess  implications  of  technologies  and 
associated  components  and  materials,  and 
provides  recommendations  for  each 
alternative.  The  PMP  Engineer  assists  to 
define  /  refine  PMP  related  strategies,  teclmologies.  and  requirements  to  support  ICD  development  and 
possibly  system  requirements  document,  e.g.,  TRD  development.  The  PMP  Engineer  also  contributes  to 
the  development  of  the  MSA  Phase  technical  products. 


MSA  Phase  -  Technical  Pro  ducts  Required 

SMC  PMP  Technical 
Products 

PMP  Contributions  to  Other 
Organizations’  Products 

High  leve!  assessment  of 
proposed  concepts, 
architectures,  technologies 

Operational  Concepts 

PMP  engineering  inputs  and 
factors  for  concept,  architecture, 
technology  studies,  and  trades 

AoA  Studies 

PMP  C  (draft) 

Initial  Capabilities  Doc  (ICD)  Dev 

PMP 
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2*  Technology  Development.  During  this 
phase  the  PMP  Engineer  continues  to 
provide  inputs  to  and  supports  the  JCIDS 
process.  The  PMP  Engineer  also  supports  all 
the  engineering  activities  highlighted  within 
the  box  titled  Engineering  Activities  for 
System  &  Segment  Development  &  Design 
Figure  23  to  commence  detailed  systems 
definition  and  development.  The  PMP 
Engineer  defines  the  requirements  for  a  PMP 
program  for  the  selection,  control,  and  qualification,  long  lead,  etc  to  meet  PMP  engineering  objectives 
and  SMC  PMP  requirements.  PMP  Engineer  develops  and  contributes  to  development  of  the  TD  Phase 
technical  products. 

3*  Engineering  &  Manufacturing 
Development,  The  PMP  Engineer  continues 
to  provide  inputs  to  and  supports  the  JCIDS 
process.  The  PMP  Engineer  supports  all  the 
engineering  activities  highlighted  witliin  the 
box  titled  Engineering  Activities  for 
Detailed  Design  Figure  23  to  commence 
detailed  systems  definition  and 
development.  The  PMP  Engineer  defines  the 
requirements  for  and  implements  a  PMP 
program  for  the  selection,  control,  and 
qualification,  parts  and  materials  purchases, 
parts  obsolescence  avoidance  sparing,  etc. 
to  meet  PMP  engineering  objectives  and 
required  SMC  PMP  requirements  per  the 
standards  cited  in  the  standards  table  abov  e.  The  PMP  Engineer  provides  inputs  to  and  supports  the  JCIDS 
process.  The  PMP  Engineer  develops  and  contributes  to  the  development  of  the  EMD  Phase  teclinical 
products. 

4*  Production  &  Deployment,  Operations  & 

Support  The  PMP  Engineer  continues  to 
ensure  the  design  meets  contractual  PMP 
requirements  and  manufacturing,  build  and 
integration  activities  do  not  induce 
additional  PMP  related  risks.  The  PMP 
Engineer  ensures  the  PMP  program 
appropriately  addresses  full  lifecycle 
requirements  for  sparing,  manufacturing 
sources,  and  preplanned  product 
improvements.  The  PMP  Engineer  develops  and  contributes  to  the  development  of  the  P&D  /  O&S  Phase 
technical  products. 


P&D  /  O&S  Phase  —  Technical  Products  Required 


SMC  PMP  Technical 
Products 

PIMP  Contributions  to  Other 
Organizations5  Products 

Inputs  tech  baseline  engineering 
changes;  finalized  SCDs,  SMDs 

Suppo  [lability  assessment  Rpt 
Contribution 

MatenaJ  review  inputs;  GIDEP 
review  and  impact  assessments 

Operational  Assessments 

Contnbutions 

Parts  derating  assessment  inputs 

Transition  &  Fielding  Docs 

Test,  Demo  assessments 

PMPSL  updates 

GIDEP  Assessments 

EMD  Phase  -  Technical  Products  Required 


SMC  PIMP  Technical 
i  Products 

PMP  Contr  ibutions  to  Other 
Organizations5  Products 

Technical  Studies/  Trades  inputs 

Operational  Concepts 

System  Tech  Reqts,  TRD,  Spec, 

I  CDs,  SCDs,  SMDs;  PMP 
requirements  flow-down  / 
allocations 

Operational  Assessments 

Inputs  to  system  design, 
production,  fielding,  sustain  docs 

Capabilities  Production  Doc 
(CPD) 

Material  review  inputs;  GIDEP 
review  and  impact  assessments 

Parts  derating  assessment  inputs 

Test,  Demo  assessments 

DPA  assessments 

PMPSL 

GIDEP  Assessments 

TD  Phase  —  Technical  Pr  oducts  Required 


SMC  PM P  Technical 
Products 

PMP  Contributions  ro  Other 
Organizations5  Products 

Inputs  to  System  Concepts 

Operational  Concepts 

Factors  for  Studies/  Trades 

Operational  Assessments 

PMP  Tech  Reqls,  TRD, 
Specifications,  ICDs,  Standards 
Selection/  Tailor 

Capabilities  Development  Doc 
(CDD) 

Prelim  Parts  and  materials  list 

Cntical  Processes  list 

PMP  related  analyses 
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PMP  Engineers'  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  then  business  model  and  approach  structure  based  primarily  on  then  program 
objectives,  program  and  technical  challenges,  organizational  structure,  as  well  as  program  and  engineering 
planning  (SEP  plus  detailed  PMP  planning  and  corrosion  prevention  planning.) 

The  PMP  Engineer  develops  and  implements  the  PMP  engineering  program  planning  to  achieve  Program 
Office  PMP  objectives  and  requirements.  The  planning  defines  the  PMP  tasks  and  functions  to  be  performed 
and  products  to  be  developed:  timing  of  tasks,  task  outputs,  resources  (skills,  tools,  equipment,  and  completion 
criteria).  The  PMP  Engineer  plans  tasks  to  integrate  PMP  activities  within  the  Program  Office,  between 
Contractors  and  stakeholders.  The  PMP  Engineer  plans  the  tasks  to  establish  and  manage  PMP  selection  and 
controls;  conduct  material,  GIDEP,  and  other  PMP  review  forums;  support  SE&I  activities,  risk  management, 
integration,  and  system  modifications;  coordinate  the  PMP  planning  with  SMC  Staff  PMP  Engineering  office, 
integrate  PMP  Engineering  planning  with  other  functional  and  acquisition  plans  (i.e.  SEP,  ASP,  LCMP). 

Execution  of  the  PMP  Engineer  planning  is  typically  defined  through  an  Operating  Instruction  wliich 
implements  SMC  and  higher  level  instructions,  policies,  and  directives.  The  PMP  Engineer  provides  full 
support  to  define  the  program  and  technical  objectives  where  PMP  challenges  and  risks  are  known  or 
anticipated.  The  PMP  Engineer  assists  to  establish  the  business  model,  develop  program  planning  and 
schedules,  and  define  and  implement  program  processes.  The  PMP  Engineer  ensures  the  PMP  components  of 
the  program  are  appropriately  represented  in  the  program  plans,  program  schedules,  work  breakdown 
schedules,  cost  estimates.  The  PMP  Engineer  also  reports  then-  technical  performance  and  progress.  The  PMP 
Engineer  shares  in  the  risk  management  responsibilities  to  identify,  assess,  and  propose  mitigating  actions  of 
PMP  related  risks.  They  also  support  the  program  manager’s  problem  identification,  resolution,  and  decision¬ 
making  processes. 


The  PMP  Engineer  contributes  to  the  development  of  the  program  management  products  identified  in  the 
Table. 


SMC  Program  Management  Products 


PMD 


SEP  IMP  IMS  WBS 


Decision-making  &  problem  solving  inputs 


Technical  progression  and  issues  reporting 


LC  Cost  Estimate  (CARDs) 


Processes  (OEs) 


Risk  Management  Inputs 


Information  Assurance 
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Appendix  R  -  Information  Assurance  Engineering 

DoD  defines  Information  Assurance  (I A)  as  T’ measures  that  protect  and  defend  information  and  information 
systems  by  ensuring  their  availability,  integrity,  authentication,  confidentiality,  and  non-repudiation.  This 
includes  providing  for  the  restoration  of  information  systems  by  incorporating  protection,  detection,  and 
reaction  capabilities  (CNSSI  No.  4009)."  All  SMC  programs  classified  as  National  Security  Space  Systems 
(NSS)  are  required  to  comply  with  DoDD  8500.01.  The  Information  Assurance  Manager  (IAM)  or  the  IA 
Engineer  (LAE),  appointed  by  the  acquisition  program  manager,  supports  the  responsibility  to  stand-up  and 
execute  the  IA  program.  LAM  or  LAE  can  be  the  same  individual,  especially  for  smaller  programs,  and  in  the 
following  description  will  be  treated  interchangeably.  This  SED  describes  necessary  tasks  and  products,  the 
policy  from  winch  they  are  derived,  their  relationship  to  the  acquisition  framework,  and  the  engineering  details 
one  should  consider  in  working  towards  effective  LA  defenses -in-depth  in  a  net-centric  environment. 


Applicable  governance,  standards,  and  guidance 

Table  23  below  identifies  the  significant  governance,  standards,  and  guidance,  which  generally  requires  SMC 
compliance  for  LA. 

Table  23  Governance,  standards,  and  guidance  that  sliape  tlie  Information  Assur  ance  Engineering  discipline 


Document  No 

Governance  Title 

Issue 

DoDD  50Q0.01 

Defense  Acquisition  System,  El.  1.9.  Information  Assure  nee 

current  as  of  2C  Nov  07 

DOD  1 5000.02 

Operation  of  the  Defense  Acquisition  System,,  "Title  40/Clmger 

Chen  Act  (CCA)“  Compliance 

08  Dec  08 

Nations!  Security 

Directive  42 

National  Policy  for  the  Security  National  Security 
Telecommunications  and  Information  Systems 

05  Jul  90 

Director  of  Central 
Intelligence  Directive 
(DCID)  6/3 

Protecting  Sensitive  Compartmented  Information  Within 

Information  Systems 

05  Jun  99 

CNSSP-12 

National  Information  Assurance  Policy  for  Space  Systems  Used  to 
Support  National  Security  Missions 

20  Mar  07 

DoDD  8500.01  E 

Information  Assurance  (IA) 

24  Oct  02 

DoDI  8500.2 

Information  Assurance  (IA)  Implementation 

f)6  Feb  03 

DoDI  8580.1 

Information  Assurance  (IA)  in  the  Defense  Acquisition  System 

09  Jul  04 

DoDD  8581 .01 

Information  Assurance  (IA)  Policy  for  Space  Systems 

C8  Jun  10 

DoDD  8570.01 

Information  Assurance  Training,  Certification,  and  Workforce 
Management 

23  Apr  07 

AFPD  63-17 

Technology  and  Acquisition  Systems  Security  Program  Protection 

26  Nov  01 

Document  No 

Standards  Title 

Issue 

NIST  SP  800.53 

Recommended  Security  Controls  for  Federal  Information  Systems 
and  Organizations  (Joint  Task  Force  Transformation  Initiative) 

Aug  09 

NIST  SP  80048 

Guide  to  Securing  Legacy  IEEE  802.1 1  Wireless  Networks 

Jul  08 

NIST  SP  800-123 

Guide  to  General  Server  Security 

Jul  C8 

Doc  time nt  No 

Guidance  Title 

Issue 

DoDI  8510.01 

DoD  IA  Certiti cation  and  Accreditation  Process  (DIACAP) 

28  Nov  07 

- 

DIACAP  Knowledge  Service  at  htlpsjTdiacapiaportal.navy.mil 

https://d  iaca  p .  ia  porta  1  rta 
vy.mil 

CNSSI  No.  4009 

National  Information  Systems  Security  Glossary  revised 

Jun  06 

DoD  5220.22-M 

National  Industrial  Security  Program  Operating  Manual  (NISPOMj 

28  Feb  2006 

- 

DASD  for  Cyber,  Identity,  and  Information  Assurance  Strategy 

Aug  09 

Defense  Acquisition 
Guidebook  (DAG) 

DAG,  Chapter  7:  Acquiring  Information  Technology,  Including 
National  Security  Systems,  Section  7.5  Information  Assu ranee 

Current  at 
https://daq.dau.miL 
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DISASTIGs 

Defense  Information  Systems  Agency  (DIS A)  Security  Technical 
Implementation  Guides  (STIG)  -  various  IA  subjects 

various 

CJCSI  6212.01  E 

Interoperability  and  Supportability  of  Information  Technology  and 
National  Security  Systems 

18  Dec  08 

IA  Engineers'  Contributions  to  the  Acquisition  Life  Cycle  Framework 

Hie  SMC  program  IA E  supports  implementation  of  statutory  and  regulatory  requirements  governing  I  A, 
handles  major  tasks  involved  in  developing  an  IA  organization,  defines  IA  requirements,  integrates  IA  in  the 
program’s  architecture,  develops  an  acquisition  IA  strategy,  collaborates  with  NS  A  in  defining  and 
implementing  cryptography  for  data  protection,  conducts  or  monitors  appropriate  IA  testing  and  validation,  and 
plans  tor  and  oversees  I A  certification  and  accreditation  for  the  program  within  DoD  acquisition  life  cycle  as 
defined  byDoDI  5000.02. 

LAE  has  the  responsibility  to  develop  an  LA  Strategy  that  the  DoD  CIO  must  certify  for  Major  Automated 
Information  System  (MAIS)  programs  or  confirm  for  Major  Defense  Acquisition  Programs  (MDAPs)  before 
each  Milestone  approval.  One  of  the  key  elements  of  this  certification  or  confirmation  is  the  DoD  CIO’s 
determination  that  the  program  has  an  I A  strategy  that  is  consistent  with  DoD  policies,  standards,  and 
architectures.  DoDI  8580.1  provides  guidance  on  howr  to  implement  policy,  assign  responsibilities,  and 
prescribe  procedures  necessary  to  integrate  IA  into  the  Defense  Acquisition  System. 

LAE  supports  the  program  to  meet  its  IA  responsibility  that  includes  Information  Systems  Security  Engineering 
(ISSE),  ciyptograpliy  certification,  C&A,  usually  through  the  DoD  Information  Assurance  Certification  and 
Accreditation  Process  (DIACAP)  process  IAW  DoDI  8500.2,  and  helps  develop  program  plans,  budgets,  and 
contracts,  as  appropriate  to  integrate  LA  mto  overall  Systems  Engineering.  LAM  also  provides  technical 
validation  of  I A  requirements  and  selection  of  lA-enabled  technology  and  products  for  space  systems  that 
facilitate  GIG  connection  and  net -centric  operations. 

Figure  24  provides  the  acquisition  life  cycle  framework  within  which  LAE  performs  as  well  as  the  products  that 
the  LAE  develops  or  contributes  to.  This  figure  and  documents  in  Table  23  provide  details  on  compliance 
requirements  to  perform  IA  planning  support  pie-  and  post-contract  awrard  acquisition  activities,  and  perform 
IA  management  and  engineering  over  the  system  hfecycle.  SMC  Program  Offices  appoint,  establish,  and 
implement  IA  program  strategies  and  objectives  consistent  with  the  tenets  of  appropriate  policies,  SMC 
acquisition  objectives,  and  program  obj  ectives.  LAM  contributions  to  the  REP  include  (i)  IA  portion  of  REP 
Section  H  (Special  Contract  Requirements)  that  identifies  IA  policy  and  requirements  for  the  design 
acquisition,  installation,  operation,  upgrade,  or  replacement  of  all  DoD  information  systems  IAW  the 
appropriate  documents  listed  in  (ii)  a  section  for  PWS/SOO  to  communicate  specific  IA  requirements, 
fimctions.  and  tasks  required  of  the  offerors,  IA  roles  to  be  performed,  specific  I A  controls  to  be  satisfied,  and 
any  specific  LA  per  formance  criteria  (e.g.,  availability  requirements);  (in)  CDRL  entries  to  incorporate  any  LA- 
related  data  products  and  documents  that  the  potential  contractor  needs  to  produce;  (iv)  LA  portion  of  REP 
Section  M,  Evaluation  Factors  for  Award,  to  list  evaluation  factors  and  significant  subfactors  by  which  the 
offers  are  evaluated  and  the  relative  importance  that  the  government  places  on  these  evaluation  factors  and 
sub-factors.  When  IA  performance  is  critical,  the  REP  may  specifically  address  the  impact  of  non-compliance 
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Acquisition  Life-Cycle  Process  for  Information  As 


Technology  Development 


Figure  24  SMC  Acquisition  life  cycle  process  for  SMC  Information  Assurance  Engineering 


Information  Assurance 
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or  lack  of  LA  performance  on  the  part  of  the  contractor,  and  may  set  up  a  system  of  rewards  and  punishment 
based  on  contractor  performance.  The  IAM  supports  the  PM  to  identify  LA  test  and  evaluation  requirements, 
metrics,  success  criteria,  and  how  and  when  best  to  conduct  the  LA  testing.  And.  if  essential  to  the  program, 
IAM  helps  develop  CLINs  to  assure  resources  for  critical  LA  technology  for  SE  design  imp le mentation  and 
integration  .requirements);  (Mi)  CDRL  entries  to  incoiporate  any  LA -related  data  products  and  documents  that 
the  potential  contractor  needs  to  produce:  (iv)  LA  portion  of  RFP  Section  M,  Evaluation  Factors  for  Award,  to 
list  evaluation  factors  and  significant  sub  factors  by  which  the  offers  are  evaluated  and  the  relative  importance 
that  the  government  places  on  these  evaluation  factors  and  sub-factors.  When  IA  performance  is  critical,  the 
REP  may  specifically  address  the  impact  of  non-compliance  or  lack  of  LA  performance  on  the  part  of  the 
contractor,  and  may  set  up  a  system  of  rewards  and  punishment  based  on  contractor  performance.  The  IAM 
supports  the  PM  to  identify  LA  test  and  evaluation  requirements,  metrics,  success  criteria,  and  how  and  when 
best  to  conduct  the  LA  testing.  And,  if  essential  to  the  program,  IAM  helps  develop  CLINs  to  as sme  resources 
for  critical  LA  technology  for  SE  design  implementation  and  integration. 

1*  Materiel  Solution  Analysis*  The  SMC  PM  establishes 
an  IA  organization  and  appoints  an  IAM/IAE.  The  IAM 
and  his  team  of  LA  engineer's  supports  LA  acquisition 
activities  to  include  (i)  identification  of  IA  requirements, 

(ii)  determination  of  program  Mission  Assurance  Category  (MAC)  and  Confidentiality  Level  (CL)  LAW 
DoDI  8500.02  for  approval  (in)  identification  of  baseline  I A  controls  consistent  with  their  MAC  and  CL 
and  other-  possible  I A  requirements  beyond  die  baseline  that  may  be  imposed  through  the  Capstone 
Requir  ements  Document  (CRD),  ICD,  (iv)  draft  of  an  LA  strategy,  a  living  standalone  document,  using  an 
IA  strategy  template  as  provided  in  DAG,  and  (v)  collaboration  with  NS  A  to  develop  a  Cryptography 
Security  Plan  (CSP)  that  utilizes  NSA-approved  cryptography  and  implementation  process.  LAM  supports 
registering  of  systems  with  the  DoD  Chief  Information  Officer  (CIO)  thr  ough  the  Component  CIO.  and 
guides  the  program  for  DoD  CIO  review  and  certification  of  the  I A  Strategy  and  the  CSP  at  Milestone  A. 
LAM  also  provides  inputs  to  the  overall  Systems  Engineering  (SEP,  TDS),  cost  estimates  (CARD), 
soLeitation/RFP  development  for  Contractor  studies,  aud  proposal  evaluation  activities  as  necessary. 

2*  Technology  Development*  If  MS  A  phase  for  a  progr  am 
is  skipped,  the  LAE  completes  all  actions  requhed  before 
MS  A.  For  MS  B,  IAM  (i)  ensures  IA  considerations  are 
incorporated  in  the  program  ASP,  (ii)  updates  and 
submits  LA  Strategy,  (iii)  secures  resources  for  IA  in  the 
program  budget  to  cover  die  cost  of  developing, 
procuring,  testing,  certifying  and  accrediting,  and 
maintaining  the  posture  of  system  LA  solutions,  (iv) 
conducts  DoD  Information  Assurance  Certification  and 
Accreditation  Process  (DIACAP)or  other  applicable 
certification  and  accreditation  (C&A)  process,  and  (v) 

updates  CSP  LAW  NS  A  guidelines  and  Information  Systems  Security  Engineering  (ISSE)  support. 


TD  Phase  —  SMC  Acquisition  Pi' o ducts 


Updates  to  Acquisition  IAS,  CSP _ 

IA  Section  in  ASF',  SEP,  and  CARD _ 

RFP:  IA  objectives  in  the  S00;  IA  related  tasks  in 
SOW,  IA  data  products  in  CDRLs;  SMC-  IA  standards  - 
tailored _ 

Inputs  to  Initial  ISP _ _ 

Initial  DIACAP  Package  for  OAA  approval  includes 
SIPp  DIP,  DIACAP  Scorecard,  POA&M,  and  supporting 
artifacts  including  IA  Control  validation  procedures  and 
tests  and  EiDTR/eMASS  registration _ 

STAR 


MSA  Phase  -  SMC  Acquisition  Products 


Acquisition  I A  Strategy  (IAS)  Cryptography  Security 
Plan  (CSP) 


IA  Section  in  ASP,  SEP,  TDS,  and  CARD 


Information  Assurance 
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3. 


Engineering  <&  Manufacturing  Development.  For  MS 
C,  the  IAE  (i)  incorporates  and  implements  IA  design 
solutions  based  on  necessary  ISSE  efforts,  (ii)  tests  and 
evaluates  IA  solutions,  (iii)  supports  C&A  activities  for 
the  system  under  DIACAP  to  obtain  necessary  approvals 
from  the  Designated  Accrediting  Authority  (DAA),  (iv) 
provides  inputs  to  and  supports  all  program  acquisition 
activities  to  include  the  development  of  updates  to  the  I A 
strategy  and  CSP,  updates  to  the  cost  estimate,  and  (v) 


EMD  Phase  -  SMC  Acquisition  Products 


Updates  to  Acquisition  IAS,  CSF,  inputs  to  ISP _ 

DIACAP  Package  for  DAA  approval  includes  SIP,  DIP, 
DEACAP  Scorecard,  PQA&M,  and  supporting  artifacts 
including  IA  Control  validation  procedures  and  tests 
and  E I DTR/eM ASS  registration _ 

RFP:  IA  objectives  in  the  S00;  IA  related  tasks  in 
SOW,  lAdata  products  in  CDRLs:  SMC- 1 A  standards  - 
tailored _ 

STAR 


supports  soiicitation/REP  development  and  proposal  evaluation  activities  to  ensure  appropriate  cost- 


effective  IA  technologies  are  acquired  to  meet  program  objectives. 


4. 


Production  &  Deployment,  Operations  &  Support. 
The  LAM  maintains  the  system's  security  posture 
throughout  its  lifecycle.  It  includes  (i)  periodic  DIACAP 
re- accreditation,  (ii)  assessment  of  IA  dining  IOT&E  on 
the  mature  system. 


P&D  /  O&S  Phase  -  SMC  Acquisition 
Products 


Updates  to  IAS,  CSP,  inputs  to  final  ISP _ 

RFP:  IA  objectives  in  the  S00;  IA  related  tasks  in 
SOW,  lAdata  products  in  CDRLs;  SMC-  IA  standards 

Periodic  DIACAP  Package  for  DAA  approval  includes 
SIP,  DIP,  DIACAP  Scorecard,  POA&M,  and  supporting 
artifacts  including  I A  Control  validation  procedures  and 
tests  and  ElDTR/eMASS  registration 


IA  Engineers’  Contributions  to  the  Engineering  Life  Cycle  Framework 

Relationship  to  SE  Organization 

The  IAE  plans  and  executes  essential  IA  engineering  and  management  efforts  in  ail  integrated  and  effective 
manner  witlim  the  context  and  full  support  of  the  overarching  Systems  Engineering  function.  LAE  ensures  that 
each  LA  SED  contribution  is  timely,  adequate,  consistent,  and  compliant.  The  LAE  ensures  that  their 
contributions  are  channeled  through  the  Systems  Engineering  Analyses  and  Control  activity. 

As  depicted  in  the  LAE  contributes  to  the  SE  process  with  I A  concept  and  architecture  development  and 
analyses,  modeling  and  simulation  efforts,  make  or  buy  (COT S/GOT S)  solutions,  and  threat,  risk,  and 
technology  studies.  IAE  ensures  I A  technical  information  is  current  and  commensurate  with  program  maturity 
and  is  appropriately  applied  through  systematic  control,  collaboration,  and  sharing  across  the  organization  to 
integrate  with  all  SE  engineering  functions  through  the  system  lifecycle.  Tliis  includes  application  of  mandated 
security  standards,  available  from  DISK  online,  as  appropriate  to  the  system  security  posture.  LAM  lays  the 
groundwork  for  a  successful  CSc A  process  by  facilitating  consensus  among  the  PM,  Component  CIO,  and  DoD 
CIO  on  pivotal  issues  such  as  MAC,  CL,  and  applicable  Baseline  LA  Controls,  selection  of  the  appropriate 
C&A  process,  id entifr cation  of  the  DAA.  and  documenting  a  timeline  for  the  C&  A  process. 

Relationship  to  other  SEDs 

IA  SED’s  relationship  to  other  SEDs  is  summarized  in  Figure  1.  As  shown  in  Figure  1,  LA  engineering 
solutions  for  the  program  strongly  depend  on  Net-Centric  Engineering  SED.  It  is  LAE's  responsibility  to  be 
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cognizant  of  the  computing  and  network  environment  and  the  data  model  for  the  program  Interoperable 
environments  require  robust  and  pervasive  network  level  IA  to  assure  Warfighter’s  data  availability,  integrity, 
and  confidentiality. 

IAE  supports  IA  test  and  evaluation  (T&E)  as  an  integral  part  of  the  overall  T&E  process.  DoD  Instruction 
5000.02  directs  that  I A  test  and  evaluation  be  conducted  during  both  Developmental  Test  and  Evaluation  and 
Operational  Test  and  Evaluation.  To  ensure  that  IA  testing  adequately  addresses  system  IA  requirements,  all 
sources  of  LA  requirements  must  be  considered.  The  primary  source  is  the  applicable  set  of  baseline  LA 
controls.  Additional  IA  requirements  may  be  imposed  through  capabilities  documents,  or  as  a  result  of  the  risk 
management  process,  or  as  directed  by  the  DoD  Components.  An  Interim  Authorization  to  Operate  or 
Authorization  to  Operate  is  required  prior  to  conducting  Operational  Test,  and  should  maintain  Interim 
Authority  to  Test  (IATT)  and  what  that  is  used  for.  These  authorizations  are  granted  only  after  the  bulk  of 
C<&A  activities  are  concluded,  and  the  DAA  is  satisfied  with  the  residual  risk  to  the  system. 


Tools  Selection  and  Use 

The  IA  Engineer  considers  effectiveness  and 
efficiencies  gained  by  selecting  and  using  the 
best  choice  of  information  assurance  tools 
considering  the  IA  tool  requirements, 
information  sharing,  automated  data  exchanges 
with  other  tools,  and  other  considerations. 


IA  Functions  Requiring  Tools 


Design  and  Architecture  Modeling 


Trade  studies  and  anaEysts  of  IA  technology,  standards,  and  products 

Requirements  Analyses  &  Allocations 


Security  standards  selection  -  DISRonline 


[A  registration  tools  e  g.,  EIDTR,  eMASS 


NS A-ap proved  cryptography  and  implementation  process  selection 

EA  V&V,  Develop  ment/Qperationat  testing 
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Engineering  Activities  and  Products  over  the  Life  Cycle 

The  following  subsections  delineate  IA  Engineer's  contributions  to  engineering  activities  and  technical 
products  byDOD  acquisition  phase. 


1.  Materiel  Solution  Analysis.  Specifically, 
during  this  phase  the  IA  Engineer  provides 
inputs  to  and  supports:  (i)  system  IA 
classification,  (ii)  the  Capabilities  Based 
Assessment  process,  (iii)  flueat  assessment, 
(iv)  risk  assessment,  (v)  Net-Ready  Key 
Performance  Parameter  (NR-KPP)  and 
interoperability  assessment.  (vi) 
cryptography  technology  and 

implementation  process  assessment  in 
collaboration  with  NSA,  and  if  initiated  (vii) 
the  DIACAP  assessment. 


2.  Technology  Development.  During  tliis 
phase  the  I A  Engineer  continues  to  provide 
inputs  to  and  supports  the  JCIDS  process. 
The  IA  Engineer  also  supports  all  the 
engineering  activities  to  update  IA  products 
described  in  the  MSA  phase.  IAE  assists 
with  developing  architectural  products  like 
the  DoDAE  viewpoints  (SV-4,  SV-6)  to 
incorporate  IA  design  concepts. 

The  IA  Engineer  develops  and  derives  IA 
requirements  and  supports  the  SE 
requirements  analyses  and  allocation 
process,  participates  hi  teclmology  studies 
and  teclmical  solutions  trades  to  ensure 
compliance  with  IA  mandates  and  security 
related  standards  selection  to  support 
certification  and  accreditation  of  the  system. 
The  IA  Engineer  also  wrorks  closely  with  the 


MSA  Phase  —  Technical  Products  Required 


SMC  L4  Technical  Products 

IA  Conti ibu Horn  to  Other 
Organizations-  Prod  nets 

System  Classification  (MAC,  CL) 

IASr  ASP 

Baseline  and  capability-based  IA 
Controls 

IAS,  ASP,  ICO,  ODD,  PWS/SOO 

Threat  assessment,  ISSE, 
Information  Operations  Capstone 
Threat  Capabilities  Assessment 

IAS,  ASP, 

Risk  Assessment 

IAS,  ASP 

Interoperability  GIG-connectivity 
assessment 

IAS 

Cryptography  Technology  and 
implementation  process  (NSA 
support) 

CSP,  ASP,  RFP 

DIACAP  assessment 

IASr  ASP 

TD  Phase  -  Technical  Products  Required 

SMC  IA  Technical  Products 

IA  Contributions  to  Other 
Organizations  •  Pr  od  u  cts 

updated  baseline  and  capability- 
based  IA  Controls 

IAS,  ASP,  ICD,  CDD,  PWS/SOO 

updated  Cryptography 

Technology  and  implementation 
process  (NSA  support) 

CSP,  ASP,  ISP,  RFP 

Technology  and  standards 
selection  studies  and  trades 

IAS,  ASP,  SEP,  TDS 

Interoperability  and  supportability 
studies  and  trades 

IAS,  SEP,  ISP 

updated  Threat  assessment 
(STAR,  ISSE,  Information 
Operations  Capstone  Threat 
Capabilities  Assessment) 

IAS,  ASP,  ISP 

updated  Risk  Assessment 

IAS  ASP,  ISP 

IA  architecture,  Interoperability 
GIG-connectivity  assessment 

IAS,  ISP 

update  DIACAP  assessment  and 
supporting  artifacts 

IAS,  ASP,  DIACAP  Package 

Test  and  evaluate  IA  solutions 

DIACAP  Package 

SEs  performing  interface  analyses,  functions!  analyses,  and  the  integration  and  verification  and  validation 
pi  aiming  and  execution.  A  more  concerted  effort  is  made  to  develop  tests  and  IA  solutions  to  validate 
required  IA  Controls.  The  IAE  in  tliis  phase  has  an  emphasis  on  I A  technology  and  standards  studies  and 
trades  to  support  SE  function  and  overall  inclusion  of  IA  requirements  in  the  system  architecture 
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Fiuthennore,  IAE  a  iso  makes  certain  that  the  Net -Ready  KPPs  are  achievable  for  uet-centric  operations 
and  interoperability,  including  implementation  of  Internet  Protocol  version  6  (EPv6)  as  necessary.  IAE 
ensures  and  supports  activities  for  the  program  (capability,  system,  and/or  service)  to  continuously  provide 
survival} le„  interoperable,  secure,  and  operationally  effective  information  exchanges  to  enable  a  net -centric 
military  capability  wliile  meeting  IA  requirements  of  availability,  integrity,  authentication,  confidentiality, 
and  non-repudiation  over  the  entire  lifecycle. 

LAE  also  provides  inputs  to  the  LA  section  of  the  ASP  that  includes  (I)  applicable  I A  policy  and  guidance 

(ii)  IA  technical  considerations  for  choosing  design  characteristics  and  solutions,  (iii)  IA  implementation 
schedule,  (iv)  cost,  (v)  funding  profile,  and  (vi)  staffing  and  support  requirements. 

3*  Engineering  &  Manufacturing 
Development.  IA  Engineer  continues  to 
provide-  inputs  to  and  supports  the  JCIDS 
process.  The  LAE  (i)  supports  engineering 
activities  to  further  dev  elop  or  modify  the  IA 
component  of  the  system  architecture,  (ii) 
ensures  LA  solution's  compliance  with  the 
Global  Information  Grid  (GIG)  architecture, 

(iii)  supports  product  selection  and 
make/buy  decision  studies  and  trades,  (iv) 
makes  maximum  use  of  enterprise  IA 
capabilities  and  services,  (v)  supports 
procurement  of  lA/IA-enabled  products  with 
emphasis  on  leveraging  COTS  hardware 
and/or  software  and  tools  (DoD  Instruction 
5000.02,  paragraph  6  of  Enclosure  5),  (v) 
helps  Implement  of  security  policies,  plans, 
and  procedures.  (vi)  continues  to  support 
technical  solutions  trades  to  ensure 
compliance  with  IA  mandates,  and  security  related  standards  selection  to  support  certification  and 
accreditation  of  the  system.  The  LA  Engineer  also  works  closely  with  the  SEs  performing  interface 
analyses,  fiuictiona!  analyses,  and  the  integration  and  verification  and  validation  planning  and  execution, 
and  (vh)  conducts  LA  Training. 

4.  Production  <&  Deployment,  Operations  & 

Support.  I A  Engineer  continues  to  provide 
inputs  to  and  supports  the  JCIDS  process. 


IA  Engineers’  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  their  business  model  and  approach  based  primarily  ou  program  objectives, 
technical  challenges,  organizational  structure,  and  required  engineering  planning  including  I A  for  cost- 
effective  execution. 


P&D  /  O&S  Phase  —  Technical  Products  Required 

SMC  LA  Technical  Products 

LA  Contributions  to  Other 
Organizations5  Products 

Periodic  re-accreditation 

DIACAP  Package 

Assess  IA  posture 

IOT&E  report 

EMD  Phase  -  Tec  lime  al  Products  Required 


SMC  LA  Technical  Products 

LA  Contributions  to  Other 
Organizations5  Products 

updated  baseline  and  capability- 
based  IA  Controls 

IASP  ASP,  1CD,  CDDr  PWS/SOO 

updated  Cryptography 

Technology  and  implementation 
process  (NS A  support) 

CSP,  ASP,  ISP,  RFP 

Product  selection  and  make/buy 
decision  studies  and  trades 

IAS,  ASP,  SEP,  ISP,  TDS 

updated  Threat  assessment 
(STAR,  ISSE,  Information 
Operations  Capstone  Threat 
Capabilities  Assessment) 

IASf  ASP,  ISP 

updated  Risk  Assessment 

IAS,  ASP,  ISP,  CSP 

updated  I A  architecture. 
Interoperability  GIG-oonnectivity 
assessment 

IAS,  ISP 

update  DIACAP  assessment  and 
supporting  artifacts 

IASr  ASP,  DIACAP  Package 

Test  and  evaluate  IA  solutions 
and  products 

DIACAP  Package 

IA  training  products 

01,  processes 
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IA  Engineer  supports  the  PM  in  meeting  overall  I A  protection  responsibility  for  the  National  Security  Systems 
(NSS)  system  IAW  the  8500  series  of  policy  and  guidance.  It  includes  definition,  development,  design, 
maintenance,  and  operation  of  interoperable  and  GIG -connected  systems  in  a  net- centric  environment  with  hill 
IA  protection. 

For  acquisitions  of  Automated  Information  Systems  (AIS), 

LAM  coordinates  with  enclaves  hosting  applications  to 
addresses  operational  security  risks  and  identifies  ail  system 
security  needs  using  baseline  IA  controls  as  a  common 
framework  to  facilitate  this  process.  The  burden  for  ensuring 
that  an  AIS  application  has  adequate  assurance  is  a  shared 
responsibility  of  both  the  AIS  application  I  AM  and  the  DM 
for  the  hosting  enclave.  However,  the  responsibility  for  initiation  of  this  negotiation  process  lies  clearly  with 
the  IAM.  I  AM,  to  the  extent  possible,  draws  on  the  common  LA  capabilities  that  can  be  provided  by  the  hosting 
enclave. 

Outsourced  IT- based  processes  must  comply  with  the  IA  requirements  in  the  8500  policy  series.  The  vendor  is 
responsible  for  delivering  outsourced  business  processes  supported  by  private  sector  information  systems, 
out  so  meed  information  technologies,  or  outsourced  information  sendees  that  present  specific  and  unique 
challenges  for  the  protection  of  the  GIG.  The  IAE  for  an  Outsourced  IT-based  process  carefully  defines  and 
assesses  the  functions  to  be  performed  and  identifies  the  technical  and  procedural  security  requirements  that 
must  be  satisfied  to  protect  DoD  information  in  the  service  provider’s  operating  environment  and 
interconnected  DoD  information  systems.  The  IA  Engineer  contributes  to  the  development  of  the  identified 
program  management  products. 

Execution  of  IA  planning  is  typically  defined  tlirough  the  IA  Strategy  document.  The  IA  Engineer  provides  fiill 
support  to  define  the  program  and  technical  objectives  where  IA  challenges  and  risks  are  known  or  anticipated. 
The  IA  Engineer  assists  to  establish  the  business  model,  develop  program  planning  and  schedules,  and  define 
and  implement  program  processes.  The  I A  Engineer  ensures  the  I A  components  of  the  program  are 
appropriately  represented  in  the  program  plans,  program  schedules,  wTork  breakdown  schedules,  cost  estimate  s. 
The  LA  Engineer  also  reports  their  teclmical  performance  and  progress.  The  IA  Engineer  shares  in  the  risk 
management  responsibilities  to  identify,  assess,  and  propose  mitigating  actions  of  LA  related  risks.  They  also 
support  the  program  manager's  problem  identification,  resolution,  and  decision-making  processes. 


SMC  Program  Management  Products 


IAS,  ASP:  FTP,  PWS,  S00  _ 

Decision-making  &  problem  solving  inputs _ 

Cost  Estimate  (CARDs)  _ 

DIACAP  Package  and  artifacts,  IA  V&V  procedures 

Developmental  and  Operational  tests _ 

Threat  Assessment  and  Risk  Management  Inputs 
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Appendix  S  -  Net-Centric  Engineering 

Network-centric  operations  and  warfare  (NCGW)  seeks  to  translate  infonnation  adjutage  into  a  competitive 
advantage  through  robust  networking  of  well-informed  geographically-dispersed  forces.  NCOW  (and  net- 
centric  engineering)  focuses  on  five  key  areas  to  realize  a  net-centric  (NC)  infonnation  sharing  vision:  (i)  data 
and  services,  (ii)  secured  availability,  (iii)  computing  infrastructure  readiness,  (iv)  coimnunications  readiness, 
and  (v)  Network  Operations  (NetOps)  agility.  DoD  envisions  moving  to  tnisted  NCOW  through  the  acquisition 
of  services  and  systems  that  are  secure,  reliable,  interoperable,  and  able  to  communicate  across  a  universal 
information  infrastructure  based  on  Internet  Protocol  (IP)  and  related  non -proprietary  and  vendor-neutral 
standards.  Tills  internetworking,  combined  with  changes  in  teclinoiogy.  organization,  processes,  and  people 
allows  new  and  robust  forms  of  organizational  behavior. 

All  SMC  programs  classified  as  National  Security  Systems  (NSS)  are  required  to  comply  with  CJCSI 
6212.01E,  Interoperability  and  Support  ability  (I&S)  of  Information  Technology  and  National  Security 
Systems,  18  December  2008.  Net-centric  Engineering  or  NCOW7  vision  is  a  major  and  enabling  part  of  the 
enterprise- wide  I&S  requirements  and  often  are  used  synonymously.  SMC  considers  tliis  new  SED  of  great 
importance  for  enliancing  space  systems  performance  and,  as  such,  joined  SFAWAR  and  other  organizations 
to  develop  tools,  requirements,  and  implementable  guidance  that  is  available  through  the  Net- Centric 
Enterprise  Solutions  for  Interoperability  (NESI)  websites  -  tliis  information  can  be  used  by  the  Net-centric 
Engineer  (NCE)  as  such  or  tailored  to  help  develop  various  acquisition  aitifacts  including  net -centric 
data/services  strategy.  ASP.  and  ISP. 

The  NCE  lias  the  responsibility  to  stand-up  and  execute  the  NCOW  program.  Tliis  SED  describes  the 
necessary  tasks  and  products,  the  policy  from  which  they  are  derived,  tlieir  relationship  to  the  acquisition 
framework,  and  the  engineering  details  one  needs  to  consider  in  working  towards  effective  assured 
information-sharing  NCOW. 

Applicable  governance,  standards,  and  guidance 

Table  24  identifies  the  significant  governance,  standards,  and  guidance  which  generally  require  SMC 
compliance  for  Net  Centric  Engineering. 

Table  24  Governance,  standards,  aiad  guidance  that  shape  tbe  Net-Centric  Engineering  discipline 


Document  No 

Governance  Title 

Issue 

DoDD  5000.01 

Defense  Acquisition  System,  El.  1.9  (Information  Assurance), 

El .1.10  (Information  Superiority),  El.  1.11  (interoperability  T&E), 

El  1 13  (Interoperability),  El.  1.1 6  (interoperability) 

current  as  of  20  Nov  07 

DoDi  5000.02 

Operation  of  tbe  Defense  Acquisition  System,  Enclosures  5  and  6 

08  Dec  08 

CJCSI  6212  01 E 

Interoperability  and  Supportability  of  Information  Technology  and 
National  Security  Systems 

18  Dec  08 

DoDD  4630.05 

Interoperability  and  Supportability  of  Information  Technology  (IT) 
and  National  Security  Systems  (NSS) 

05May  04 

DoD!  4630.8 

Procedures  for  Interoperability  and  Supportability  of  Information 
Technology  (IT)  and  National  Security  Systems  (NSS) 

30  Jun  04 

CJCSM  3170.01  C 

Operation  of  the  Joint  Capabilities  Integration  and  Development 
System,  01  May  2007 

DoD  IT  Standards  Registry  (DISR) 

current  at  http ://disron line. 

Net-Centricitv 
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disa.mil. 

DoDD  8000.01 

Management  of  the  Do D  Information  Enterprise 

lOFeb  09 

DoDD  8320.02 

Data  Sharing  in  a  Net-Centric  Department  of  Defense,"  December 

2, 2004 

IPv6  Memos 

09  Jun  03  and  29  Sep  03 

Document  No 

Standards  Title 

Issue 

Applicable  (Program  Specific)  government  and  industry  standards 
listed  in  the  DoD  Information  Technology  Standards  Registry 
(DISR) 

Various 

Document  No 

Guidance  Title 

Issue 

DoD  Net-Centric  Services  Strategy 

Mar  07 

DoD  Net-Centric  Data  Strategy 

09  May  03 

DoD  NetOps  Strategic  Vision 

Dec  08 

DoD  Global  Information  Grid  (GIG)  Architecture 

Aug  03 

DoD  Architecture  Framework  (DoDAF) 

Nov  08 

DoD  832G.2-G,  "Guidance  for  Implementing  Net-Centric  Data 
Sharing" 

12  Apr  06 

DoD  CIO  Net-Centric  Checklist 

AFSPC  NC  Checklist 

Net-Centric  Enterprise  Solutions  for  Interoperability  (NESI) 

current  at  http://nesipublic. 
spawarnavy.mil. 

NESI  Open  Source  site 

https://nesi.spawar. 
navy.mil/accounl / 
request  php 

Defense  Acquisition 
Guidebook  (DAG) 

DAG,  Chapter  7:  Acquiring  Information  Technology,  Including 
National  Security  Systems,  Section  7.3  Interoperability  and 
supportability  and  Section  7.4  Net-centric  Information  Sharing 

Current  at 
https://dag.dau.mil/ 

Planning  Guide/Roadmap  Toward  IPv6  Adoption  within  the  US 
Government  -  CIO  Council 

May  09 

NCE's  Contributions  to  the  Acquisition  Life  Cycle  Framework 

The  Program  Office  NCE  supports  implementation  of  statutory  and  regulatory  requirements  governing  NCOW 
that  includes  NSS  system  acquisitions  that  effectively  implements  the  inaudated  I&S  objectives  and 
requirements.  The  NCE:  (i)  implements  NR-KPPs  in  the  program's  architecture,  requirements,  and 
acquisitions,  (ii)  leads  the  development  of  an  Information  Support  Plan  (ISP)  to  document  the  Program's 
compliance  with  I&S  and  NC  mandates,  and  (iii)  supports  program  acquisition  activities  and  products  to 
ensure  net  centric  engineering  is  fully  integrated  into  the  acquisition  strategies,  planning,  RTFs,  source 
selection,  and  post-contract  execution  functions  and  processes.  An  equally  important  part  of  the  NCE 
responsibilities  is  to  stand-up  and  manage  the  necessary  Community  or  Communities  of  Interest  (COI)  to  meet 
the  intent  of  DoDD  8320.02  in  sharing  user  data  that  is  visible,  accessible,  and  understandable  hi  a  trusted 
environment. 


The  NCE  implements  the  NR-KPPs  through  assessment  and  determination  of  NR-KPP  information  needs,  data 
and  services  strategy,  information  timeliness.  Information  Assurance  (IA),  and  net -ready  attributes  required  for 
both  the  teclmical  exchange  of  information  and  the  end-to-end  operational  effectiveness  of  that  exchange.  The 
NCE  ensures  that  NR-KPPs  are  sufficiently  defined  to  include  verifiable  performance  measures  and  associated 
metrics  needed  to  evaluate  timely  sharing  of  information  for  a  given  capability.  The  NCE  uses  the  NR-KPP 
documented  in  Capability  Development  Document  (CDD)  and  Capability  Production  Document  (CPD)  to 
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analyze,  identify,  and  describe  IT  (includes  ail  NSS)  interoperability  needs  in  the  ISP  and  in  the  test  strategies 
in  the  Test  and  Evaluation  Master  Plan. 

The  NCE  activities  to  achieve  NR-KPP  compliance  include: 

•  Supports  integrated  architecture  products,  including  the  Joint  Common  Systems  Function  List 
required  to  assess  information  exchange  and  operationally  effective  use  for  a  given  capability: 

•  Implements  DoD  Net-centric  Data  and  Services  strategies,  including  data  and  sendees  exposure 
criteria  IAW  8320.02: 

•  Ensures  compliance  with  applicable  Global  information  Grid  (GIG)  Technical  Direction  to  include  (i) 
use  of  the  mandated  DoD  IT  Standards  Registiy  (DISK),  (ii)  development  of  mandated  (CJCSI 
6212.01)  DoDAF  viewpoints  to  meet  the  Net  Centric  Engineering  requirements; 

•  Verifies  compliance  with  DoD  IA  requirements  IAW  8500.02;  and 

•  Ensures  compliance  with  Support  ability  elements  to  include  Spectnun  Analysis,  Selective 
Availability  Anti- Spoofing  Module,  and  the  Joint  Tactical  Radio  System. 

The  NCE  along  with  the  Program  Office  team  of  engineers  supports  acquisition  activities  to  include:  (I) 
identification  of  NCOW  requirements,  (ii)  initiation  of  analyses  and  relevant  data  to  develop  the  Information 
Support  Plan  (ISP)  or  Enhanced  ISP  (EISP)  or  Tailored  ISP  (TISP),  (iii)  identification  of  data  that  the  program 
needs  to  or  is  required  to  share,  based  on  ICD/CDD,  (iv)  identification  of  possible  users  across  and  beyond  the 
DoD.  (v)  initiation  and  management  of  COIs  as  necessaiy  to  develop  vocabularies  and  sendee  descriptions 
and,  (vi)  augmentation  of  existing  DoD  Discovery  Metadata  Specification  (DDMS)  and  Net -centric  Enterprise 
Services  (NCES)  to  enable  NCOW  operations,  if  new  metadata  or  services  are  defined.  NCE  provides  this  data 
as  inputs  to  the  program  acquisition  activities  and  products  that  include  ASP,  TDS,  DMS:  cost  estimates 
(CARD).  soficitation/RFP  development,  and  proposal  evaluation  activities  as  necessary. 

The  NCE  is  solely  responsible  for  and  leads  the  development  of  the  ISP  -  a  repository  of  IT  that  focuses 
information  on  net-readiness.  I&S,  NR-KPP  compliance,  and  information  sufficiency  concerns.  ISP  ensures  a 
means  to  identify  and  resolve  potential  implementation  issues  and  risks  that  can  potentially  restrict  the  ability 
of  a  program  to  perform  as  required.  The  NCE  validates  the  ISP  based  on  analysis  of  the  program's  integrated 
architecture  as  developed  in  the  mandated  DoDAF  viewpoints.  This  analysis  identifies  information  need,  net- 
centric  and  I&S  issues,  and  assesses  compliance  with  DoD  CIO  policy  and  goals.  Guidance  for  the  mandatory 
format  and  content  of  the  ISP  is  provided  hi  DoDI  4630.8,  enclosure  4,  and  CJCSI  6212.01.  The  Joint  Staff 
utilizes  the  ISP  hi  the  I&S  Certification  process:  J2  utilizes  the  ISP  for  intelligence  supportability  (CJCS 
Instruction  3312.01). 

NCE  contributions  to  the  RFP  Include:  (i)  portions  of  SOO,  SOW/PWS,  and  attached  or  referenced  technical 
requirements  documents  —  TRD  or  acquisition  specification  and  any  specific  I&S  performance,  technology, 
and  open- standards  compliance  requirements  such  as  IPv6 -cap  able,  EPsec  in  Section  C  communicating  specific 
I&S  requir  ements,  functions,  and  tasks  required  of  the  offerors, ,  (ii)  I&S  CDRLs  in  Section  J  to  incorporate 
any  I&S -related  data  products  and  documents  that  the  potential  contractor  needs  to  produce,  (iii)  special 
contract  requirements  in  Section  H  that  identifies  I&S  policy  and  requirements  for  the  design,  acquisition, 
installation,  operation,  upgrade,  or  replacement  of  all  DoD  information  systems  IAW  the  appropriate 
documents  listed  in  Table  24  (iv)  section  for  PWS/SOO  to  (iii)  section  hi  CDRL.  (iv)  specify  data  rights  in 
Section  J,  (v)  I&S  related  proposal  instructions  in  Section  L  to  include  reusability  requirements  requiring 
component-based  SW,  layered  architecture,  and  SOA,  (vi)  I&S  specific  proposal  evaluation  factors  for  aU'ard 
hi  Section  M,  and  (vii)  any  post -award  considerations  that  are  important  to  the  program  When  I&S 
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performance  is  critical,  the  REP  specifically  addresses  the  impact  of  lion-coiupliance  or  lack  of  I&S 
performance  on  the  pait  of  the  contractor,  and  can  set  up  a  system  of  rewards  and  punishment  based  on 
contractor  performance.  The  NCE  supports  the  PM  to  identify  I&S  test  and  evaluation  requirements,  open- 
standards  compliance  metrics,  success  criteria,  and  how  and  when  best  to  conduct  the  I&S  testing.  When 
essential  to  the  program,  NCE  helps  develop  CLINs  to  assure  resources  for  critical  I&S  technology  for  SE 
design  implementation  and  integr  ation.  It  is  recommended  that  NCE  draw  on  and  tailor  Net -Centric  Enterprise 
Solutions  for  Interoperability  (NESI)  guidance  as  applicable,  and  possibly  include  Parts  3,  4,  and  5  as  reference 
or  guidance  documents  hi  the  REP. 

Figure  25  shows  the  NCE  contributions  and  required  products  within  the  DoDI  5000.02  phased  acquisition 
lifecycle  framework.  This  figure  delineates  die  Program  Office  NCE  responsibilities  and  requirements  to 
perform  NCE  planning,  support  pre-  and  post-contract  award  acquisition  activities,  and  performs  NCE 
management  and  engineering  across  the  system  lifecycle,  consistent  with  the  tenets  of  appropriate  policies. 
SMC  acquisition  objectives,  and  overall  program  systems  engineering  objectives.  The  Program  Office  NCE 
helps  develop,  attain  approval  lor.  and  implement  the  Information  Support  Plan  (ISP)  and  related  artifacts  to 
comply  with  I&S  requirements  hi  accordance  with  current  DoD  policy. 

1.  Materiel  Solution  Analysis,  During  this  phase, 
the  NCE  helps  establish  an  NCOW  organization 
for  the  Program  Office  to  support  acquisition 
activities  that  include  (i)  identification  of  NCOW 
requirements  including  NR-KPP  compliance,  (ii) 
identification  of  data  that  the  program  is  required 
to  share  based  on  ICD/CDD,  (iii)  identification  of  possible  users  across  and  beyond  DoD,  (iv) 
organization  and  management  of  COIs  as  necessary  to  develop  vocabularies  and  service  descriptions  to 
possibly  augment  existing  DoD  Discovery  Metadata  Specification  (DDMS)  and  Net -centric  Enterprise 
Services  (NCE  S),  (v)  initiation  of  I&S  analyses  and  generation  of  relevant  data  including  Do  DAE 
viewpoints  as  mandated  and  listed  in  CJCSI  6212.01,  and  (vi)  initiation  of  cost  estimates  for  implementing 
NC  requirements  for  the  ISP.  The  NCE  generates  technical  analyses  and  data  that  are  then  used  by  the 
overall  program  SE  organization  to  produce  an  integrated  system  design  that  is  documented  in  SEP,  TRD, 
TDS.  CPD.  and  CARD.  NCE  also  supports  REP  development  and  proposal  evaluation  activities.  While 
ISP  is  not  requir  ed  until  MS  B,  the  foregoing  engineering  analyses  and  data  can  be  documented  in  an  ear  ly 
draft  (recommended). 


MSA  Phase  —  SMC  Acquisition  Products 


i&S  inputs  (NCOW  requirements,  NC  data/services  strategy, 
Vocabularies/service  descriptions)  for  ISP,  CPD,  TRD,  ASP, 
SEP,  TDS,  and  CARD  _ 

Architecture  products  (DoDAF  Viewpoints)  QVs,  CVs _ 

Draft  ISP 
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2.  Technology  Development.  NCE  helps  define  all 
information  needs  and  related-dependencies  including 
data  rights  according  to  DoD  Instinct  ion  4630.8,  CJCSI 
6212.01.  CJCSI  3170.01.  and  the  JCIDS  Manual  to 
ensure  LfcS  is  addressed  in  the  ISP  and  CDD.  NCE 
updates  required  DoDAP  products  as  listed  hi  the  CJCSI 
6212.01  and  NR-KPP  compliance  for  the  ISP  and  ASP. 

NCE  updates  NC  data /sendees  strategy  using  the  COI  as 
necessary.  NCE  submits  the  Initial  ISP  for  formal 
coord  mated  review  according  to  DoD  Instruction  4630.8.  NCE  Tailors  and  incorporate  SMC/NESI  I&S 
and  NCE  requirements  in  SOO.  SOW.  and  RFP  as  needed. 

3.  Engineering  &  Manufacturing  Development.  Before 
CDR  NCE  develops  a  revised  ISP  updating  all 
information  needs  and  related- dependencies  according  to 
DoDI  4630.8,  CJCSI  6212.01.  CJCSI  3170.01.  and  the 
JCIDS  Manual  to  ensure  information  supportability  is 
fully  addressed.  NCE  updates  DoD  AT  viewpoints,  NR- 
KPP  compliance,  and  tailored  NCE  requirements  for  ISP, 

SOO,  SOW,  and  RTP  as  needed.  NC  data/services 
strategy  is  also  updated  using  the  COI  as  needed. 

NCE  produces  the  Tina  I  ISP  before  MS  C  in  compliance  with  the  mandates.  The  Pinal  ISP  is  submitted  for 
review  and  acceptance  conducted  by  J2  and  J6  to  issue  intelligence  certifications  and  LfcS  certifications  as 
required  in  CJCSI  3312.01  and  6212.01.  NCE  helps  guide  the  ISP  through  DoD  CIO  approval  and 
submission  to  JCPAT-E  as  the  Final  ISP  of  Record.  The  Pinal  ISP  of  Record  is  required  for  Joint 
Interoperability  Test  Command's  Interoperability  Test  Certification. 

4.  Production  &  Deployment,  Operations  &  Support, 

After  Pinal  Build  Approval  for  Space  Programs  (or  after 
Milestone  C),  NCE  Submits  an  updated  ISP  for  minor 
upgrades  that  does  not  require  a  frill  review  process. 

However,  for  each  major  upgrade  (e.g.,  block  or 
increment),  NCE  submits  an  updated  ISP  for  formal, 
coordinated.  Initial  ISP  Review  according  to  DoD 
Instruction  4630.8. 


P&D  /  O&S  Phase  -  SMC  Acquisition 
Products 


Updated  Final  ISP  when  required _ 

Updated  Architecture  products  (DoDAF  Viewpoints) 
l&S  inputs  (NCOW  requirements,  NC  data/sen/ices 
strategy,  Vocabularies/service  descriptions)  for  ISP, 
CPD,  TRD,  ASP,  SEPr  TPS,  ard  CARD  _ 

RFP  l&S  and  NCE  objectives  in  the  SOO;  l&S,  NCE, 
and  related  tasks  in  SOW,  l&S  and  NCE  data  products 
in  CDRLs;  tailored  SMC/NESI  l&S  and  NCE 
requirements 


EMD  Phase  —  SMC  Acquisition  Products 


Revised  ISP  (before  CDR),  Final  ISP  (before  MS  C) 

Revised  Architecture  products  (DoDAF  Viewpoints) 
l&S  inputs  (NCOW  requirements,  NC  data/services 
strategy,  Vocabularies/service  descriptions)  for  ISP, 
CPD,  TRD,  ASP,  SEP:  IDS,  and  CARD 
RFP:  l&S  and  NCE  objectives  in  the  SOO;  l&S,  NCE, 
and  related  tasks  in  SOW,  l&S  and  NCE  data  products 
in  CDRLs;  tailored  SMC/NESI  l&S  and  NCE 
requirements 


TD  Phase  —  SMC  Acquisition  Products 


Initial  ISP _ 

Update  Architecture  products  (DoDAF  Viewpoints) 

l&S  inputs  (NCOW  requirements,  NC  data/services 
strategy,  Vocabu lanes/service  descriptions)  for  ISP, 
CPD,  TRD,  ASP,  SEP.  TPS,  and  CARD _ 

RFP:  l&S  and  NCE  objectives  in  the  SOO;  j&S,  NCE, 
and  related  tasks  in  SOW,  l&S  and  NCE  data  products 
in  CDRLs;  tailored  SMC/NESI  l&S  and  NCE 
requirements 


NCEs'  Contributions  to  the  Engineering  Life  Cycle  Framework 

Relationship  to  SE  Organization 

The  NCE  addresses  NCOW  fiom  an  enterprise  arcliitecture  perspective.  As  part  of  the  overall  mission  and 
system  design,  the  NCE  defines  and  applies  a  collection  of  policies,  standards,  methodologies,  services,  and 
mechanisms  to  maintain  mission  integrity  with  respect  to  people,  process,  technology,  information,  and 


Ne t- Cerifri city  SMC  Specialty  Engineering  Disciplines  241 

supporting  infrastructure.  The  objective  is  to  ensure  enterprise -wide  data -centric  discoverable  information 
availability  within  a  shared  and  protected  environment.  Given  mission  objectives  and  system  design.  NGE 
articulates  and  integrates  a  coherent  structure  of  NC  sendees  and  mechanisms,  develops  an  NC  Framework, 
NC  operational  processes,  and  as  a  part  of  the  systems  engineering  function,  assists  integration  of  NCOW/NR- 
KPP  compliance  requirements  into  the  system  at  the  earliest  time  possible  hi  the  acquisition  process.  A  weil- 
executed  NC  "design  for  system/ enterprise"’  leads  to  a  visible,  accessible,  institutional,  understandable,  trusted, 
and  best  protected  hifonnation  system  with  known  risks  and  shortfalls.  The  NCE  ensures  that  their 
contributions  are  channeled  through  the  Systems  Engineering  Analyses  and  Control  activity  (Figure  25). 

As  depicted  hi  Figure  25  the  NCE  contributes  to  the  SE  process  with  Net  Centric  Engineering  concept  and 
architecture  development  and  analyses,  modeling  and  simulation  efforts,  make  or  buy  (COTS/GOTS) 
solutions,  cost  estimates,  and  threat,  risk,  and  technology  studies.  NCE  ensures  technical  information  is  current 
and  commensurate  with  program  maturity  and  is  appropriately  applied  through  systematic  con  hoi, 
collaboration,  and  sharing  across  the  organization  to  integrate  with  all  SE  engineering  functions  through  the 
system  lifecycle.  This  includes  application  of  mandated  Net  Centric  Engineering  and  I&S  standards,  especially 
those  available  from  DISRonline,  as  appropriate. 

Tools  available  to  NCE  to  implement  NCOW/NR-KPP  requirements  include  NESI,  a  cross -service  effort  with 
SMC  participation  that  implements  DoDI  4630.8  interoperability  process.  NESI  provides  actionable  guidance 
to  achieve  NCOW  I&S  goals  addressing  architecture,  design,  and  implementation.  It  offers  compliance 
checklists,  specific  design  and  engineering  knowledge,  and  recommendations  to  implement  NC  solutions.  NCE 
tailors  and  implements  NESI  guidance  commensurate  with  program  maturity  as  necessary. 

Community  of  Interest  (COI)  is  an  informal  and  loosely  coupled  organization  construct  that  enables  a  "group 
of  users  that  must  exchange  hifonnation  in  pursuit  of  its  shared  goals,  niter  ests,  missions,  or  bus  hie  ss  processes 
and  therefore  must  have  shared  vocabulary  for  the  hifonnation  exchanges’'  (DoD  8320.2).  NCE  lays  the 
groundwork  for  a  successful  COI  process,  recruiting  ad  lioc  members  from  formal  organizations  w7ho  may 
produce,  develop,  or  consume  program  data  as  necessary.  Witliin  the  COI  collaborative  environment,  NCE  (i) 
helps  delineate  betw  een  a  program’s  public  and  private  data  sets  and  services,  (ii)  develops  information  sharing 
or  service  level  agreements  with  other  organizations,  and  (ii)  helps  make,  disseminate,  and  maintain  program 
vocabulaiy.  ontology,  and  fonnal  schemas  for  sharing  and  reuse. 

Support  required  of  NCE  over  the  acquisition  lifecycle  of  the  system  ensures  that: 

•  system  is  Internet  Protocol  (IP)  compliant,  has  IPv6  -cap ability,  employs  vendor-neutral  and  non- 
proprietary  standards,  and  offers  highest  possible  quality  of  service: 

•  program  developed  hifonnation  is  shared  with  commensurate  authentication,  confidentiality,  availability, 
and  integrity: 

•  data  and  services  strategy  is  consistent  with  timely  discovery  and  availability,  authoritative  posting  of  data 
for  reuse,  and  assured  sharing. 

Relationship  to  other  SEDs 

NCE  SED ’s  relationship  to  other  SEDs  is  summarized  in  Figure  1 . 

Relationship  with  LA  Engineering*  The  NCE’s  solutions  for  the  program  strongly  depend  on  the  I A  SED  for 
authorization  and  hifonnation  confidentiality  and  integrity.  It  is  NCE’s  responsibility  to  be  cognizant  of  the 
computing  and  network  environment,  the  DIACAP  process  and  required  IA  controls,  the  cryptographic  support 
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plans,  and  the  data  model  for  the  program.  This  information.  as  developed  in  the  IA  Strategy  and  CCA 
compliance  documents,  is  summarized  in  the  ISP.  Interoperable  environments  require  robust  and  pervasive 
wire-level  IA  to  assure  Warfighter's  data  availability,  integrity,  and  confidentiality.  NCE  supports  the  LAE  to 
ensure  technical  validation  of  I A  requirements  through  the  DLACAP  process  LAW  DoDI  8500.2,  supports 
cryptography  certification,  and  supports  selection  of  LA-enabled  technology  and  products  for  space  systems 
that  facilitate  GIG  connection  and  net-centric  operations. 

Relationship  with  Software  Engineering.  To  accommodate  an  internetworking  environment,  software  design 
must  evolve  from  traditional  platform-centric  to  the  NC  construction.  Data-  and  service-oriented  NC 
architecture  require  SW  design  that  can  no  longer  be  conducted  in  a  sandbox,  but  must  reach  out  to  open  and 
vendor-neutral  internetworking  standards  and  protocols.  NCE  assists  the  SW  engineer  in  analyzing  the  design 
and  in  the  implementation  of  a  data -centric  solution  that  leads  to  a  net- centric  battlefield. 

Relationship  with  Architecture  Engineering.  DoD  enterprise  to  make  critical  information  widely  available 
requires  close  coordination  of  its  constituent  systems  and  organizations.  Tills  is  possible  only  when  component 
architectures  across  all  programs  are  designed  with  data-  and  service-orientation  to  create  a  seamless 
information-sharing  construct.  In  this  respect,  NCE  assists  architectural  engineer  in  developing  various 
DoBAE  arti facts  that  facilitate  internetworking,  but  especially  the  operational,  system,  and  service  viewpoints. 
NCE.  in  collaboration  with  the  COIs,  also  helps  with  the  development  of  the  architectural  vocabulary  and 
schema  like  the  AV-2  to  ensure  data  is  discoverable  and  understandable. 

Relationship  with  T&E.  NCE  supports  Net  Centric  Engineering  test  and  evaluation  (T&E)  as  an  integral  part 
of  the  overall  T&E  process  as  mandated  for  both  Developmental  Test  and  Evaluation  and  Operational  Test  and 
Evaluation.  NCE  ensures  that  testing  adequately  addresses  system  NR-KPP  compliance  and  that  the  necessary 
verification  and  validation  requirements  are  incorporated  in  the  Master  T&E  plan.  NCE  also  supports  the 
Program  Office  to  help  develop  program  plans,  budgets,  and  contracts,  as  appropriate  to  integrate  NCOW  into 
overall  Systems  Engineering. 


Typical  NCE  Functions  Requiring  Tools 


Tools  Selection  &  Use 

The  NCE  considers  effectiveness  and  efficiencies  gained  by 
selecting  and  using  the  best  choice  of  NCE  tools  that  are 
conducive  to  information  sharing,  automated  data  exchanges 
with  other  tools,  and  other  considerations. 


Design  and  Architecture  Modeling _ 

Make  or  Buy  decision,  COTS  product  selection _ 

Trades  and  analyses  of  NCE  technology,  standards, 
and  products _ 

Requirements  Analyses  &  Allocations _ 

NCE  standards  selection  -  DISRonline _ 

DoD  CiQ  NCOW  Checklists _ 

NESI  tools  and  guidance _ 

NCE  government  and  industry  V&V,  Development/ 
Operational  testing 


N&t-  Cen  fricib' 


SMC  Specialty  Engineering  Disciplines 


243 


Engineering  Activities  and  Products  over  the  Life  Cycle 

Hie  following  subsections  delineate  NCEfs  contributions  to  engineering  activities  and  technical  products  by 
D  CD  acquisition  p  ha  s  e . 


1.  Materiel  Solution  Analysis.  Specifically, 
during  tills  phase  die  NCE  provides  inputs  to 
and  supports  (i)  the  Capabilities  Based 
Assessment  process,  (ii)  inclusion  ofNCOW 
requirements  in  system  and  operational 
concepts,  (in)  development  of  data  model, 
vocabularies  and  schema  with  COI 
participation  as  necessary,  (iv)  NR-KPP  and 
I&S  assessment,  (v)  identification  of 
mandated  and  applicable  open  standards, 
and  (vi)  IA  and  cryptography  technology 
environment. 


MSA  Phase  —  Technical  Products  Required 

SMC  NCE  Technical 

Products 

NCE  Contilbutioiis  to  Other 
Organizations’  Products 

Draft  ISP 

CPD.TRD,  IAS,  ASP 

COI  products 

Vocabulary,  data  products, 
service  definitions 

l&S/NC  Risk  Assessment 

IAS,  ASP 

Interoperability  GIG-oonnectivity 
assessment 

Data  model,  service  descriptions, 
tailored  D1SR  standards 

NR-KPP  assessment 

!ASr  ASP 

DoDAF  Viewpoints 

TRD,  SEP 

consistent  with  DIACAP  assessment  in  a  net -centric 


2.  Technology  Development.  Duiing  this 
phase  the  NCE  continues  to  provide  inputs 
to  and  supports  the  JCIDS  process.  The  NCE 
also  supports  all  the  engineering  activities  to 
update  NCE  products  described  in  the  MS  A 
phase.  NCE  assists  development  of  requir  ed 
DoDAF  viewpoints  as  listed  in  the  CJCSI 
6212.01. 

The  NCE  develops  and  derives  NCE 
requirements  and  supports  the  SE 
requirements  analyses  and  allocation 
process,  participates  hi  technology  studies 
and  technical  solutions  hades  to  ensure 
compliance  with  NR-KPF  mandates,  and  NC 
as  well  as  security  related  standards  selection  in  support  ofNCOW.  The  NCE  also  works  closely  with  the 
SEs  performing  interface  analyses,  functions!  analyses,  and  the  integration  and  verification  and  validation 
planning  and  execution.  A  more  conceited  effort  is  made  to  develop  tests  and  net  centric  engineering 
solutions  to  validate  the  required  NR-KPPs.  The  NCE  in  this  phase  has  an  e  nip  ha  sis  on  NC  technology 
and  standards  studies  and  trades  to  support  SE  function  and  overall  inclusion  of  NCE  requirements  in  the 
system  architecture.  Furthermore,  NCE  also  makes  certain  that  the  NR-KPP  is  achievable  for  NCOW 
operations  and  interoperability,  including  implementation  of  IPv6 -cap ability  as  necessary.  NCE  ensures 
and  supports  activities  for  the  program  (capability,  system,  and/or  service)  to  continuously  provide 
survivable,  interoperable,  secure,  and  operationally  effective  information  exchanges  to  enable  a  net-centric 
military  capability  while  meeting  LA  requirements  of  availability,  integrity,  authentication,  a ccount ability, 
confidentiality,  and  non-repudiation  over  the  entire  lifecycle. 


TD  Phase  —  Technical  Products  Required 


SMC  NCE  Technical 

Products 

NCE  Contributions  to  Other 
Organizations"  Products 

Initial  ISP 

CRD,  TRD,  IAS 

Updated  COI  products 

Vocabulary,  data  products, 
service  definitions 

Technology  and  standards 
selection  studies  and  trades 

IAS,  TRD,  ASP,  SEP,  TDS 

Interoperability  and  supportabifity 
studies  and  trades 

IAS,  SEP,  TRD,  CPD 

Updated  Risk  Assessment 

IAS,  ASP 

Interoperability  GIG-connectivity 
assessment 

Data  model,  service  descriptions, 
tailored  D! SR  standards 

NR-KPP  assessment 

IAS,  ASP 

DoDAF  Viewpoints 

TRD,  SEP 

Test  and  evaluate  NCE  solutions 

TRD,  Desiqn  Architecture 

NCE  cost  analysis 

ASPf  CARD 
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NCE  also  provides  inputs  to  the  net  centric  engineering  section  in  the  ASP  that  includes:  (i)  applicable 
NCOW  policy  and  guidance,  (ii)  technical  considerations  for  choosing  design  characteristics  and 
solutions,  (iii)  implementation  schedule,  (iv)  cost,  (v)  fluid ing  profile,  and  (vi)  staffing  and  support 
requirements. 

3*  Engineering  &  Manufacturing 
Development.  The  NCE  continues  to 
provide  inputs  to  and  supports  the  JCIDS 
process.  The  NCE:  (i)  supports  engineering 
activities  to  further  develop  or  modify  the 
NC  component  of  the  system  architecture, 

(ii)  ensures  NCE  solutions  are  compatible 
with  IP  and  related  vendor-neutral  open 
standards  and  comply  with  the  GIG 
architecture,  (iii)  assists  in  product  selection 
and  make/buy  decision  studies  and  trades. 

(iv)  makes  maximum  use  of  NCES 
capabilities,  (v)  supports  procurement  of 
NC -enabled  and  IPv6 -capable  products  with 
emphasis  on  leveraging  COTS  HW/SW  and  tools  (DoD  Instruction  5000.02,  paragraph  6  of  Enclosure  5), 
(vi)  helps  Implement  NCOW  policies,  plans,  and  procedures,  (vii)  continues  to  support  technical  solutions 
trades  to  ensure  compliance  with  NR-KPP  mandates  to  include  security  related  standards  selection  to 
support  certification  and  accreditation  of  the  system,  (viii)  organizes  and  manages  COIs  to  solicit 
feedback,  develop  vocabularies,  and  define  services  as  necessary,  and  (ix)  conducts  NCOW  training.  The 
NCE  also  works  closely  with  the  SEs  performing  interface  analyses,  functional  analyses,  and  the 
integration  and  verification  and  validation  planning  and  execution. 

4.  Production  &  Deployment,  Operations  & 

Support.  NCE  submits  an  updated  ISP  for 
minor  upgrades  that  does  not  require  a  full 
review  process.  For  each  major  upgrade 
(e.g.,  block  or  increment),  NCE  submits  ail 
Updated  ISP  for  formal,  coordinated,  initial 
ISP  Review  according  to  DoD  Instruction 
4630.8.  NCE  also  helps  maintain  data  model  products  and  services  for  the  operational  phase  of  the 
program. 

NCE's  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  its  business  model  and  approach  based  primarily  on  program  objectives,  teclinical 
challenges,  organizational  structure,  and  required  engineering  piainiing  including  NCE  for  cost-effective 
execution. 


P&D  /  O&S  Phase  -  Technical  Products  Required 


SMC  NCE  Technical 
Products 

NCE  Contributions  to  Other 
Organizations’  Products 

updated/initial  ISP  for  increments 

increment  CPD,  TRD 

maintenance  of  data  modeJ  and 
products ,  services 

operational  documents 

EMD  Phase  —  Technical  Pr o ducts  Required 


SMC  NTT  Technical 

Pro  ducts 

NCE  Contributions  to  Other 
Organizations’  Products 

Revised/final  ISP 

CPD,  TRD,  IAS 

Updated  COI  products 

Vocabulary,  data  products, 
service  definitions 

Technology  and  standards 
selection  studies  and  trades 

IAS,  TRD,  ASP,  SEP,  TDS 

Interoperability  and  supportability 
studies  and  trades 

IASr  SEP,  TRD,  CPD 

Updated  Risk  Assessment 

IAS,  ASP 

Interoperability  GIG-connectivity 
assessment 

Data  model,  sen/ice  descriptions, 
tailored  DISR  standards 

NR-KPP  assessment 

IASr  ASP 

DoDAF  Viewpoints 

TRD,  SEP 

Test  and  evaluate  NCE  solutions 

TRD,  Design  Architecture 

Net-Cenfricit}? 
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NCE  supports  the  PM  in  meeting  overall  NCOW  environment 
responsibility  for  the  NSS  system  IAW  applicable  policy  and 
guidance.  It  includes  definition,  development,  design, 
rna hitena nee.  and  operation  of  interoperable  and  GIG- 
counected  system  in  a  net-centric  environment  with  full  I A 
protection.  NCE  also  identifies,  arranges  for,  and  integrates 
outsourced  IT- based  processes  and  services  to  meet  unique 
challenges  for  the  protection  of  the  GIG. 


SMC  Program  Management  Products 


IAS,  ASP  RFP,  PWS,  SOG,  TRD 


Decision-making  &  problem  solving  inputs 


Cost  Estimate  (CARDs) 


Developmental  and  Operational  tests 


Threat  Assessment  and  Risk  Management  Inputs 


The  NCE  develops  and  implements  the  NCE  program  planning  to  achieve  N C O W/NR-KPP  objectives  and 
requirements.  The  planning  defines  the  NCE  tasks  and  functions  to  be  performed  products  to  be  developed: 
timing  of  tasks,  task  outputs,  resources  (skills,  tools,  equipment,  and  completion  criteria).  The  NCE  plans  tasks 
to  integrate  NCE  activities  within  the  program  office,  between  contractors  and  COI  stakeholders.  The  NCE 
plans  the  tasks  to  establish  and  manage  information  support  plan  and  documents  it  in  the  ISP.  The  NCE 
interacts  with  other  specialty  engineers  and  the  program  organization  to  ensure  internetworking  mandates  and 
objectives  are  met  in  the  SW,  Architecture  Engineer  big,  T&E.  and  the  overall  SE. 


Execution  of  the  NCE  planning  is  typically  defined  tlnough  an  01  The  NCE  provides  full  support  to  define  the 
program  and  technical  objectives  to  help  counteract  implementation  challenges  and  risks.  The  NCE  ensures  the 
NCE  development  and  management  components  of  the  program  are  appropriately  represented  in  the  program 
plans,  program  schedules,  work  breakdown  schedules,  and  cost  estimates.  The  NCE  reports  on  te clinical 
performance  and  progress  to  the  program,  shares  in  the  risk  management  responsibilities,  and  supports  the 
program  manager's  problem  identification,  resolution,  and  decision  making  processes. 
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Appendix  T  -  Environmental  Engineering 

Environmental  engineering  is  a  well- defined  and  established  SMC  discipline.  Instructions,  guidance,  and 
senior  expert  SMC  Staff  resources  are  available  to  assist  the  Program  Office  Envii  omnental  Engineer  stand  -up 
and  execute  the  essential  environmental  engineering  activities  for  the  Program  Office.  Much  of  the 
Environmental  Engineers'  activities  include  implementation  of  the  Environmental,  Safety,  and  Operational 
Health  (ESOH)  mandates  and  best  practices,  In  fact,  ESOH  is  accomplished  by  a  team  of  Environmental 
Engineers.  Systems  Engineers,  System  Safety  Engineers.  Reliability  Engineers.  Design  Engineers,  and  others 
that  understand  their  responsibilities  to  collaborate  to  achieve  the  ESOH  objectives  and  requirements.  The  full 
intent  is  to  identify  potential  environmental*  safety,  and  operational  health  problems  as  early  as  possible  hi  the 
product  lifecycle  to  provide  greater  opportunities  to  eliminate  hazards.  As  design  decisions  are  made  and  the 
development  efforts  transition  to  production  and  fielding,  ESOH  related  design  improvements  may  be  orders  of 
magnitude  more  expensive. 

The  Environmental  Engineer  plans  and  executes  the  essential  environmental  engineering  and  management 
efforts  in  an  integrated  and  effective  manner  to  ensure  that  each  enviiomnental  SED  contribution  is  timely, 
adequate,  consistent,  and  compliant.  The  Enviiomnental  Engineer  POC  ensures  that  theu  engineering 
contributions  are  channeled  tluough  the  Systems  Engineering  Analyses  and  Control  activity. 

Enviroiunental  Engineering  objectives  include  i 

1.  Establish  environmental,  safety,  and  operational  health  requirements  based  on  public  law. 
Government  policy  and  mandates,  operational  constraints,  and  SMC  practices. 

2.  Propose  teclinical  solutions  and  evaluate  the  inherent  ESOH  implications  of  proposed  technical 
solutions  to  influence  technical  decisions  to  meet  the  environmental,  safety,  and  operational  health 
requirements. 

Applicable  governance,  standards,  and  guidance 

Policy,  directives,  and  instructions  that  mandate  SMC  environmental  engineering  related  program  requir  ements 
are  included  in  a  wide  range  of  mandates  including  those  providing  requirements  for  acquisition.  Systems 
Engineering,  T&E,  Human  Systems  Integration  (HSI),  and  others. 

The  DoDI  5000.02  Environmental  /  ESOH  related  mandates  for  SMC  acquisition  programs  include: 

1 .  Implementation  of  statutory  requir  ement  applicable  to  MDAPs  and  MAIS  Acquisition  Progr  ams  for 
PESHE  (Including  National  Environmental  Policy  Act  (NEPA)  /  (Executive  Order)  E.O.  12114 
Compliance  Schedule)  Sections  4321^1347  of  title  42,  U.S.C.  required  at  MS  B.  MS  C,  Full-Rate 
Production  DR.  (or  Full  Deployment  DR) 

2.  Human-factors  engineering  to  design  systems  that  require  minimal  manpower;  provide  effective 
training;  can  be  operated  and  maintained  by  users;  and  ar  e  suitable  (habitable  and  safe  with  minimal 
environmental  and  occupational  health  hazar  ds)  and  survivable  (for  both  the  crew  and  equipment). 

3 .  The  Program  Manager  (PM),  Lead  Systems  Engineer  /  Chief  Engineer,  Environmental  Engineer  and 
System  Safety  Engineer  ensure  that  appropriate  HSI  and  Environment,  Safety,  and  Occupational 
Health  (ESOH)  efforts  are  integrated  across  disciplines  and  into  Systems  Engineering  to  determine 
system  design  characteristics  that  can  minimize  the  risks  of  acute  or  chronic  illness,  disability,  or 
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death  or  injury  to  operators  and  mainta biers:  and  enhance  job  performance  and  productivity  of  the 
personnel  who  op eiate.  maintain,  or  support  the  system. 

4.  The  Environmental  Engineer  and  System  Safety  Engineer  ensure  integration  of  ESOH  risk 
management  into  the  overall  Systems  Engineering  process  for  all  developmental  and  sustaining 
engineering  activities.  As  part  of  risk  reduction,  the  Environmental  Engineer  and  System  Safety 
Engineer  supports  the  PM  to  eliminate  ESOH  hazards  where  possible,  and  manage  ESOH  risks  where 
hazards  cannot  be  eliminated.  The  Environmental  Engineer  and  System  Safety  Engineer  ensures  the 
acquisition  program  reviews  and  fielding  decisions  address  the  status  of  all  liigh  and  serious  risks,  and 
applicable  ESOH  technology  requirements.  Prior  to  exposhig  people,  equipment,  or  the  environment 
to  known  system-related  ESOH  hazards,  the  Environmental  Engineer  and  System  Safety  Engineer 
assists  the  PM  to  document  that  the  associated  risks  have  been  accepted  by  the  following  acceptance 
authorities:  the  CAE  for  high  risks,  PEO-level  for  serious  risks,  and  the  PM  for  medium  and  low  risks. 
The  user  representative  shall  he  part  of  tills  process  throughout  the  life  cycle  and  shall  provide  formal 
concurrence  prior  to  ail  serious-  and  high-risk  acceptance  decisions. 

The  SMC  Systems  Engineering  Standard  SMC -S -001  also  provides  requirements  for  the  Environmental 
Engineer  when  chartered  to  perform  the  standard  Environmental,  Safety  and  Occupational  Health  (ESOH): 

L  Provide  ESOH  requirements  (system  and  allocated) ,  baselined  and  traceable  to  the  system  level 

2.  Identify  hazards,  analyze  hazards  including  handling  and  disposal,  propose  and  evaluate  mitigation 
decisions 

3.  Ensure  compliance  to  National  Environmental  Policy  Act  (NEPA)  and  Programmatic  Environmental, 
Safety  and  Health  Evaluation  (PE SHE)  requirements 

4.  Define  ESOH  risks  and  collective  actions  and  alternatives  to  eliminate  or  reduce  environmental, 
health,  and  identified  hazards  and  unsafe  conditions:  Identify  the  threat  of  regulatory  violations. 

5.  Establish  criteria  for  monitoring  and  reporting  of  pollution  e  lh  uination/r  eduction  efforts. 

6.  Develop  containment  program,  including  procedures  for  safe  use  and  disposal. 

7.  Include  handling  and  disposal  of  hazardous  material  in  life-cycle  cost  estimates. 


Table  25  below  identifies  the  significant  governance,  standards,  and  guidance  wliich  generally  require  SMC 
compliance  for  Environmental  Engineer ing. 

Table  25  Governance,  standards,  and  guidance  that  sliape  Cie  Environmental  Engineering  discipline 


Document  TSo 

Governance  Title 

Issue 

NEPA,  National  Environmental  Policy  Act 

DoDI  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

DoD!  6055.1 

DoD  Safety  and  Occupational  Health  (SOH)  Program 

19  Aug  08 

DoDI  6050.05 

DoD  Hazard  Communication  Program 

15  Aug  06 

DoDI  6055.07 

Mishap  Investigation,  Reporting  and  Recordkeeping 

03  Oct  00 

DoDD  6055.9E 

Explosives  Safety  Management  and  the  DoD  Explosives  Safety  Board 

19  Aug  05 

CJCSM  3170.01 

Operation  of  the  Joint  Capabilities  Integration  and  Development 

System 

24Jun  03 

AFPD  63-12 

Assurance  of  Operational  Safety,  Suitabitity,  and  Effectiveness 

01  Feb  00 

AFI 91-301 

Air  Force  Occupational  and  Environmental  Safety,  Fire  Prevention, 
and  Health  (AFOSH)  Program 

01 Jun  96 

AFI 63-1201 

Life  Cycle  Systems  Engineering 

23  Jul  07 

SMCI 63-1205 

Space  Systems  Safety  Policy,  Process,  and  Techniques 

20  Aug  07 

Title  42 
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AFPD  90-8 

Environment,  Safety,  &  Occupational  Health  (ESOH) 

01  Sep  04 

AF 132-7061 

Environmental  Impact  Analysis  Process  (EIAP) 

12  Mar  03 

AF 132-7080 

Pollution  Prevention 

12  May  94 

AFI 32-7086 

Hazardous  Materials  (HAZMAT)  Management 

01  Nov  04 

Document  TSo 

Standards  Title 

Issue 

SMC-S-015 

End-of-Life  Disposal  of  Satellites  in  Geosynchronous  Altitude 

19  Mar  10 

NAS  411 

Hazardous  Materials  Management  Program 

19  Jan  95 

AFSPCMAN  91-710 

Range  Safety  User  Requirements  Manual 

01  Jul  04 

AFSPCMAN  91-711 

Launch  Safety  requirements  for  AF  Space  Command  Organizations 

Document  IN  a 

Guidance  Title 

Issue 

Air  Force  System  Safety  Handbook 

Jul  00 

AFJMAN  24-204 

Prepanng  Hazardous  Materials  for  Military  Air  Shipments 

AFISC’s  Introduction  to  System  Safety  for  Managers 

AFSCP  127-1 

System  Safety  Program  Management 

ASDP 127-1 

System  Safety  Management 

SMC  Programmatic  Environmental,  Safety,  And  Health  Evaluation 
(PESHE)  Guide 

25  Feb  02 

The  list  of  Data  Item  Descriptions  (DIDs)  provided  below  correlate  with  the  tasks  of  Mil-Std-882C 
deliverables.  SMCI  63-1205  provides  the  associations  of  these  and  additional  DIDs  with  S82C  as  well  as 
recommended  tailoring.  Data  Item  Description  DI-HFAC-80746B  describes  equipment  which  interfaces  with 
operators.  The  human  engineering  design  emphasis  expands  to  environmental  factors  including  operator  life 
support  systems,  protective  clothing  and  equipment,  noise,  vibration,  radiation,  temperature  ambient 
illumination,  climatic  effects,  and  other  relevant  environmental  parameters. 


Date  Item  Title 

Date  Item  Description  (DID) 

Hazardous  Materials  Management  Program  Plan 

Di-MGMT-81398 

Hazardous  Materials  Management  Program  (HMMP)  Report 

D1-MISC-81 397A 

Explosive  Ordnance  Disposal  Data 

DI-SAFT-80931B 

Human  Engineenng  Design  Approach  Document-Operator 

DI-HFAO80746B 

System  Safety  Hazard  Report 

DI-SAFT-80101A  ; 

Health  Hazard  Assessment  Report 

D1-SAFT-80106A 

Mishap  Risk  Assessment  Report 

DI-SAFT-80109A 

Environmental  Engineers'  Contributions  to  Acquisition  Life  Cycle 
Framework 

Tlie  DoD  acquisition  life  cycle  is  defined  by  DoDI  5000.02.  Environmental  engineering  contributions  over  this 
life  cycle  are  best  represented  within  the  phase  of  acquisition.  Figure  26  provides  the  acquisition  life  cycle 
framework  within  which  Environmental  Engineers  perform  as  well  as  the  products  that  the  Environmental 
Engineers  develop  or  contribute  to  then  development.  This  figure  provide  the  requirements  to  perform 
environmental  engineering  planning,  support  pre  and  post  contract  award  acquisition  activities,  and  perform 
environmental  engineering  and  management  across  the  system  lifecycle.  SMC  Program  Offices  establish  and 
implement  environmental  engineering  program  strategies  and  objectives  consistent  with  the  tenets  of 
appropriate  policies,  SMC  acquisition  objectives,  and  program  objectives.  The  Program  Office  develops, 
attains  approval  for,  and  implements  environmental  engineering  planning  into  the  Systems  Engineering  Plan 
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(SEP)  and  higher  level  integrated  planning  (e.g.,  IMP)  in  accordance  with  current  DoD  policy.  This  planning  is 
firmly  based  on  program  and  technical  objectives,  strategies.  DoD  mandates,  and  instructions. 

An  effective  environmental  engineering  progr  am  supports  all  of  the  major  acquisition  activities  through  the  fill! 
system  life  cycle.  The  Environmental  Engineer  sufficiently  defines  the  environmental  engineering  program 
planning  to  achieve  the  environmental  engineering  and  overall  program  objectives  and  requirements.  The 
planning  specifies  tasks  and  functions  to  be  performed,  timing  of  tasks,  re  some  es  required ,  and  products  to  be 
developed.  This  planning  then  forms  the  basis  for  the  development  of  the  program  environmental  engineering 
or  ESOH  Instruction  (OI)  and  the  PESHE.  The  environmental  engineering  planning  and  OI  are  then  reflected 
appropriately  in  the  WBS,  IMS,  PESHE,  and  other  program  documents  that  address  environmental  engineering 
related  elements.  The  Environmental  Engineer  delineates  the  strategy  for  integrating  ESOH  into  the  systems 
engineering  process  and  describes  the  ESOH  management  approach  iu  the  PESHE.  The  environmental 
engineering  planning  is  executed  concurrently  with  the  Program  Office  Operating  Instruction  that  documents 
the  process  to  perform,  control,  and  integrate  all  environmental  engineering  and  management  activities  for 
each  phase  of  acquisition. 

The  SMC  Program  Office  enviromnental  engineering  planning  (usually  contained  hi  the  SEP  and  the  detailed 
environmental  engineering  program  planning)  and  OI  are  also  based  upon  the  appropriate  program -approved 
life  cycle.  The  folio  whig  subsections  delineate  environmental  engineering  contributions  to  acquisition 
activities  and  products  by  DOD  acquisition  Phase. 

1.  Materiel  Solution  Analysis.  During  this  phase  the 
Environmental  Engineer  provides  inputs  to  and  supports 
most  program  acquisition  activities  to  include  the 
development  of  the  acquisition  strategy,  inputs  to  the  cost 
estimates,  solicitation/RFP  development  for  Contractor 
studies,  and  proposal  evaluation  activities.  The 
Environmental  Engineer  prepares  an  initial  Hazardous 
Material  Management  Strategy  and  supports  the  System 
Safety  Engineer  to  prepare  the  draft  Systems  Safety 
Management  Plan  (SSMP)  /  Systems  Safety  Program 
Plan  (SSPP).  The  Environmental  Engineer  also  contributes  to  the  development  of  the  MSA  Phase 
acquisition  products. 


MSA  Phase  —  SMC  Acquisition  Products 


PMD _ 

ASP;  TPS,  DMS,  TES 

LC  Cost  Estimate _ 

RFP  inputs  (environmental  /  ESOH  requirements, 
ESOH  assessment  requirements;  High  level  ESOH 
assessments  of  concepts _ 

j  .  E,  CCA _ 

Preliminary  /  draft  Hazardous  Material  Management 
Strategy _ 

SEP,  LCMP 
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Technology  Development.  Hie  Environmental  Engineer 
prepares  tJie  initial  PESHE  and  an  updated  MS  B  PESHE 
to  include  the  NEPA  Strategy,  Environmental  Engineer 
provides  inputs  to  and  supports  all  program  acquisition 
activities  to  include  the  development  of  the  acquisition 
strategy,  updates  to  the  cost  model  and  development  of 
the  Cost  .Analysis  Requirements  Description  (CARD), 
solicitation/RFP  development  and  proposal  evaluation 
activities.  The  Environmental  Engineer  identifies  other 


ID  Phase  -  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  QMS _ 

LG  Cost  Estimate  Update  /  CARD  Development _ 

RFP  ESOH  objectives  m  the  SOG,  ESOH  related 
tasks  in  SOW,  ESOH  data  products  in  CDRLs;  SMC- 
Environmentat  standards  -  tailored _ 

PESHE  (Including  NEPA  strategy) _ 

APB:  ESOH  objectives  &  related  concept  descriptions 
Detailed  ESOH  planning  HMMP,  SSMP  /  3SPP,  SEP, 
LCMP.LCSPJEMP,  PDRSDAR 


environmental  related  contract  requirements,  environmental  related  tasks,  test  &  demo  requirements  to 


meet  environmental  engineering  objectives.  The  Environmental  Engineer  also  contributes  to  the 
development  and  updates  to  the  TD  Phase  acquisition  products. 


EMD  Phase  -  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS 


CARD  update 


RFP  ESOH  objectives  in  the  SQO;  ESOH  related 
tasks  in  SOW,  ESOH  data  products  in  CDRLs,  SMC- 
Environmentat  Engineering  standards  -  tailored 


HMMP:  SSMP  /SSPP;  PESHE  NEPA 


3*  Engineering  <&  Manufacturing  Development.  The 
Environmental  Engineer  provides  inputs  to  and  supports 
all  program  acquisition  activities  to  include  updates  to  the 
acquisition  strategy  and  up  dates  to  the  cost  model  to 
reflect  the  actual  technical  solutions  determined  and 
updates  to  the  CARD,  Environmental  Engineer  supports 
the  solicitation/RFP  development  and  proposal  evaluation 
activities  which  include  providing  the  technical  inputs 
including  technical  requirements,  compliance  standards, 
engineering  approaches,  incentives,  and  warranty 
programs  to  meet  program  objectives.  The  Environmental 
Engineer  identifies  other  contract  requirements  as 
necessaiy  to  meet  environmental  engineering  objectives. 

Environmental  Engineer  also  contributes  to  the  development  and  updates  to  the  EMD  Phase  acquisition 
products. 


APB:  ESOH  objectives  &  related  concept  descriptions 


Detailed  ESOH  planning,  SEP,  LCMP,  LCSP,  TEMP 
updates,  DSD  Planning,  Preliminary  EQLP,  CDR 
SOAR 


HMMP:  SSMP /SSPP:  PESHE 


APB:  ESOH  objectives  &  related  concept  descriptions 


Detailed  ESOH  planning,  SEP,  LCMP,  TEMP  updates 


During  EMD  the  Environmental  Engineer  documents  hazardous  materials  in  the  Programmatic 
Environment.  Safety,  and  Occupational  Health  Evaluation  (PESHE)  and  ensures  that  the  SMC  Program 
Office  estimates  and  plans  for  the  system’s  demilitarization  and  safe  disposal.  The  demilitarization  of 
energetic  materials  (including  any  item  containing  propellants,  explosives,  or  pyrotechnics)  must  be 
considered  during  system  design. 
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4.  Production  &  Deployment,  Operations  &  Support* 

The  Environmental  Engineer  provides  inputs  to  and 
supports  all  program  acquisition  activities  to  include 
updates  to  the  acquisition  strategy  and  updates  to  the  cost 
model  to  reflect  the  actual  technical  solutions  determined 
and  updates  to  the  CARE).  The  Environmental  Engineer 
supports  the  soiicitation/RFP  development  and  proposal 
evaluation  activities.  The  Environmental  Engineer 
identifies  other  contract  requirements:  production  and 
field  test  &  demo  requirements:  field  performance  and  sustainment  analyses  to  meet  Environmental 
Engineering  objectives.  At  the  end  of  its  useful  life,  the  Environmental  Engineer  ensures  that  the  system  is 
demilitarized  and  disposed  of  m  accordance  with  ail  legal  and  regulatory  requirements  and  policy  relating 
to  ESOH  (including  explosives  hazards),  security,  and  the  environment. 

Environmental  Engineers'  Contributions  to  Engineering  Life  Cycle 
Framework 

Relationship  to  the  SE  Organization 

The  Environmental  Engineer  plans  and  executes  the  essential  environmental  engineering  and  engineering 
management  efforts  in  an  integrated  and  effective  maimer  within  the  context  and  full  support  of  the 
overarching  Systems  Engineering  function.  The  Environmental  Engineer  ensures  that  their  SED  contributions 
are  timely,  adequate,  consistent,  and  compliant.  The  Environmental  Engineer  ensures  that  their-  contributions 
are  channeled  tlnough  the  Systems  Engineering  Analyses  and  Control  activity. 

Systems  Engineers  manage  the  engineering  process  and  activities  depicted  in  Figure  3  while  the  Environmental 
Engineer  contributes  to  this  process.  Environmental  Engineers  support  concept  and  architecture  development 
and  analyses:  modeling  and  simulation  efforts:  technology  studies  when  potentially  imp  acted  environmental 
challenges.  The  Environmental  Engineers  develop/derive  ESOH  related  requirements  and  supports  the 
requirements  analyses  and  allocations  process.  They  also  participate  in  teclmical  studies  and  technical  solutions 
trades  when  environmental  engineering  is  a  factor.  They  provide  design  analyses  contributions  to  determine 
potential  hazards.  They  assess  and  propose  alternative  mitigating  actions  or  solutions.  The  Environmental 
Engineer  also  works  closely  with  the  System  Engineers  performing  interface  analyses  and  functional  analyses 
to  leverage  the  required  ESOH  related  analyses.  The  Environmental  Engineer  also  supports  the  integration  and 
verification  and  validation  planning  and  execution. 

In  performing  the  management  and  control  function,  the  Systems  Engineer  effectively  integrates  all 
engineering  functions  through  the  full  system  life  cycle.  The  Environmental  Engineer  ensures  their-  technical 
contribution  to  the  overall  engineering  advances  and  is  appropriately  applied  tlnough  systematic  control, 
collaboration  and  sharing  across  the  organization.  For  example,  their-  assessment  products,  e.g.,  hazards 
assessments,  are  timed  to  coincide  with  architectural  trades,  design  trades,  reliability  analyses  (fault  tree, 
failiue  modes,  critical  items  lists,  reliability  block  diagrams,  etc).  In  addition  the  Environmental  Engineering 
products  are  timed  and  applied  by  the  other  Specialty  Engineers  to  perform  their  unique  contributions,  and 
must  be  provided  to  technical  and  program  management  for  decision  making. 


P&D  /  O&S  Phase  -  SMC  Acquisition 
Products 


Updates  to  ASP,  TPS,  DMS _ 

RFP:  ESOH  objectives  in  the  S00;  Safety  related 
tasks  in  SOW,  ESOH  data  products  in  CDRLs;  SMC- 
Safety  standards  -  tailored _ 

HMMF;  SSMP  /  SSPP,  PESHE _ 

Detailed  ESOH  planning,  SEP,  LCMP,  LCSP,  TEMP 
updates.  Final  SPAR,  Draft  EQLP _ 

CARD  update 
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Relationship  to  other  SEDs 
The  Environmental  Engineer  SED  relationsliip  to  other  SEDs  is  summarized  in  Figure  1.  Environmental 
Engineer  interactions  with  the  other  SEDs  are  critical  to  perform  and  integrate  their  engineering  contributions 
to  the  system  development  efforts. 

Environmental  Engineers  team  with  the  System  Safety  Engineers  and  Reliability  Engineers  to  perform  system 
hazards  analyses  to  determine  items  or  functions  when  performed  or  whose  failure  could  lead  to  a  hazardous 
system  state  —  one  that  could  result  in  unintended  death,  inj  ury,  loss  of  property,  or  environmental  harm). 

Environmental  Engineers  work  closely  with  Human  Systems  Integration  to  design  systems  that  can  be  operated 
and  maintained  by  users:  and  are  habitable  and  safe  with  minimal  environmental  and  occupational  health 
hazards.  When  failure  analyses  results  indicate  potential  hazards  hup  acts,  the  Environmental  Engineer  assists 
to  adjust  reliability  allocations  and  ensure  confidence  hi  attaining  ESQH  requirements  through  analyses,  demo, 
and  test.  Figure  16  illustrates  how  the  Environmental  Engineer  contributes  to  the  analyses  aud  inte grates  that 
effort  with  die  Systems  Engineer,  Safety  Engineer,  Reliability  Engineer,  and  Risk  Manager.  The 
Environmental  Engineer  works  closely  with  the  Logistics  Engineers  performing  maintenance  and  sustainment 
analyses  to  identify  and  address  hazards  related  issues  or  risks. 

Tools  Selection  and  Use 

The  Environmental  Engineer  considers  effectiveness  and 
efficiencies  gained  by  selecting  and  using  the  best  choice  of 
Environmental  Engineering  tools  considering  the  ESOH  tool 
requirements  possibly  for  hazards  analyses,  information 
sharing,  automated  data  exchanges  with  other  tools,  and  other 
considerations. 

Engineering  Activities  and  Products  over  the  Life  Cycle 

Engineering  activities  that  are  unique  to  environmental  engineering  include: 

•  Identify,  evaluate,  and  control  hazards  throughout  the  system's  life  cycle. 

•  Define  and  document  mishap  risk  levels  including  associated  mishap  risk  acceptance  processes. 

•  Establish  a  program  that  manages  and  documents  the  probability  and  severity  of  all  hazards  associated 
with  development,  use  and  disposal  of  the  system. 

•  Manage  ail  ESOH  risks  in  a  manner  that  is  cost  effective  and  consistent  with  mission  requirements. 

•  Ensure  that  mandated  environmental  requirements  are  established  and  implemented  for  all  space 
systems.  Environmental  Engineering  includes  the  control  and  minimization  of  hazards  related  to 
orbital  debris,  collision  avoidance,  laser  clearing-house  functions,  environmental  hazards,  and  safety 
procedures. 

•  Align  with  the  System  Safety  Engineers  to  establish  an  explosives  safety  program  that  ensures 
munitions,  explosives,  and  energetics  are  properly  hazard  classified,  and  safely  developed, 
manufactured,  tested,  transported,  handled,  stored,  maintained,  demilitarized,  and  disposed.  Comply 
with  DoD  explosives  safety  requirements  in  ail  acquisition  programs  that  include  or  support 
munitions,  explosives,  or  energetics.  Evaluate  and  manage  the  use  and  selection  of  energetic  materials 
and  the  design  of  munitions  and  explosive  systems  to  reduce  the  possibility  and  the  consequences  of 


Typical  Environmental  Engineering 
Functions  Requiring  Tools 


Hazards  identification,  analyses  &  reporting _ 

Incidents  &  action  tracking _ 

Fault  tree,  failure  modes;  probabilistic  failure 
analyses  (See  RAM  SED)  
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any  munitions  or  explosives  mishap  to  optimize  the  trade-off  of  munitions  reliability  against 
unexploded  ordinance  liability. 

Environ  mental  Analysis  and  Impact  Assessment,  An  environmental  analysis  is  performed  to  determine  the 
impact  on  and  by  each  system  product  and  process  alternative.  Proposed  environmental -related  tradeoffs  and 
analyses  are  presented  through  the  System  Engineering  process  to  determine  balanced  technical  solutions 
which  the  Environmental  Engineer  is  a  part  of. 

The  Environmental  Engineer  ensures  adherence  to  all  applicable  statutes  and  to  contractually  designated 
hazardous  material  lists;  analyzes  factors  such  as  noise  pollution,  quantities  and  types  of  hazardous  materials 
used,  hazardous  waste  disposal,  and  other  defined  environmental  requirements  as  applicable;  defines  and 
assesses  methods  to  mitigate  problems  and  impacts  identified  from  this  analysis;  includes  the  results  of  these 
assessments  into  effectiveness  analyses  as  well  as  system  definition,  design,  and  verifications;  documents 
analysis  output  appropriate  to  the  acquisition  phase  and  use  in  conjunction  with  cost  and  performance  analyses 
outputs  to  support  acquisition  phase  exit  criteria;  avoids  use  of  materials  that  present  a  known  hazard  to  the 
environmental;  includes  environment -critical  characteristics  of  people,  product,  and  process  solutions,  and 
then  risks  included  in  risk  management  process. 

Disposal  Analysis  and  Assessment.  The  Environmental  Engineer  contributes  disposal  analyses  and 
assessments  to  support  development  of  people,  product,  and  process  solutions  to  dispose  of  products  and  by¬ 
products.  Proposed  disposal-related  tradeoffs  and  other  analyses  are  presented  through  the  System  Engineering 
process  to  determine  balanced  technical  solutions  which  the  Environmental  Engineer  is  a  part  of. 

The  Environmental  Engineer  identifies  environmental  factors  for  process  waste  and  output  as  well  as  used 
products  and  components:  evaluates  effective  disposal  methods  for  system  parts  and  materials  and 
requirements  for  new  or  modified  methods,  including  storage,  dismantling,  demilitarization,  reusing,  recycling, 
and  destruction:  identifies  costs,  sites,  responsible  agencies,  handling  and  shipping,  supporting  items,  and 
applicable  federal,  state,  local,  and  host  nation  regulations  as  factors,  and  includes  disposal -critical 
characteristics  of  people,  product,  and  process  solutions  and  their  risks  in  the  program  risk  management 
process. 

The  following  subsections  delineate  Environmental  Engineer  contributions  to  engineering  activities  and 
technical  products  by  DOD  acquisition  phase. 


256  SMC  Specialty  Engineering  Discipl hies  Environmental  Engineer 

1*  Materiel  Solution  Analysis*  Dining  tills 
phase  the  Environmental  Engineer  may 
provide  inputs  to  and  support  the 
Capabilities  Based  Assessment  process  and 
the  JCEDS  process.  Tlie  Environmental 
Engineer  evaluates  proposed  concepts  and 
architectures  to  identify  and  assess 
implications  of  energetic  materials, 
explosives.,  hazardous  materials  and  provide 
recommendations  for  each  alternative.  The 
Environmental  Engineer  assists  to  define  / 
refine  ESOH  related  requirements  to  support 
IC'D  development  and  possibly  TRD  development.  The  Environmental  Engineer  also  contributes  to  the 
development  of  the  MSA  Phase  technical  products. 


MSA  Phase  -  Technical  Products  Required 


SMC  ESOH  Technical 

Products 

ESOH  Contributions  to 
Other  Organize  lions* 
Products 

High  level  assessment  proposed 
concepts  &  architectures 

Operational  Concepts 

Environmental  engineenng  inputs 
and  factors  for  concept, 
architecture,  technology  studies, 
and  trades 

AoA  Studies 

ESOH  Req’ts  (draft) 

Initial  Capabilities  Doc  (ICO)  Dev 

Roadmap  and  architectural  inputs 
-  Identification  &  mitigations  of 
potential  hazards 

DoDAF  CVs,  OVs 

2*  Technology  Development.  During  this 
phase  the  Environmental  Engineer  continues 
to  provide  inputs  to  and  supports  the  JCEDS 
process.  The  Environmental  Engineer  also 
supports  all  the  engineering  activities 
liighlighted  within  the  box  titled 
Engineering  Activities  for  System  &  Segment 
Development  &  Design  Figure  26  to 
commence  system  definition  and 
development.  Environmental  Engineer 
develops  and  contributes  to  development  of  the 

3*  Engineering  &  Manufacturing 
Development*  Environmental  Engineer 
continues  to  provide  inputs  to  and  supports 
the  JCEDS  process.  The  Environmental 
Engineer  supports  all  the  engineering 
activities  highlighted  within  the  box  titled 
Engineering  Activities  for  Detailed  Design 
Figure  26  to  commence  detailed  systems 
definition  and  development.  The 
Environmental  Engineer  ensures  process  is 
in  place  to  report,  a lialyze,  and  mitigate 
hazards  data  dining  DT&E.  The 
Environmental  Engineer  provides  inputs  to 
and  supports  the  JCIDS  process.  The 


TD  Phase  —  Technical  Pr o ducts  Required 


SMC  ESOH  Technical 
Products 

ESOH  Contributions  to 
Other  Organiza lions' 
Products 

Inputs  to  System  Concepts 

Operational  Concepts 

Factors  for  Studies/  T rades 

Operational  Assessments 

ESOH  Tech  Req?ts,  TRD;  SRD, 
Specifications,  ICDs,  Standards 
Selection/  Tailor 

Capabilities  Development  Doc 
(CDD) 

ESOH  inputs  to  ISP 

DoDAF  CVs,  OVs 

Prelim  hazards  list 

PESHE 

TD  Phase  tedmical  products. 

EMD  Phase  —  Technical  Pro  ducts  Required 

SMC  ESOH  Technical 
Products 

ESOH  Contributions  to 
Other  Organizations  * 
Products 

Update  System  Concept 

Operational  Concepts 

Technical  Studies/  Trades 

Operational  Assessments 

System  Tech  Reqts,  TRD,  SRD, 
Spec,  ICDs;  ESOH  requirements 
flow-down  /  allocations 

Capabilities  Production  Doc 
(CPD) 

Inputs  to  system  design, 
production,  field inq,  sustain  docs 

DoDAF  CVs,  OVs 

PESHE  Update 

Environmental  Enp  inputs  to  ISP 

Hazards  analyses/report 

ESOH  evaluations  of  Tech 
Orders,  operations  manuals 

Test,  Demo  reports 

Environmental  Engineer  develops  and  contributes  to  the  development  of  the  EMD  Phase  technical 
products. 
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4.  Production  &  Deploy incut,  Operations  & 

Support*  The  Environmental  Engineer 
continues  to  ensure  design  meets  the 
contractual  environmental  engineering 
requirements  and  manufacturing,  build  and 
integration  activities  do  not  induce 
additional  hazard  risks.  The  Environmental 
Engineer  ensures  the  ESOH  program 
appropriately  addresses  end-of-life  safiug, 
and  space  environments  per  AFSPC 
Supplement  to  AFI  91-202.  The 
Environmental  Engineer  develops  and  contributes  to  the  development  of  the  Production  &  O&S  Phase 
technical  products. 

Environmental  Engineers'  Contributions  to  Program  and  Project 
Management 

Each  SMC  program  defines  their  business  model  and  approach  structure  based  primarily  on  their  program 
objectives,  program  and  technical  challenges,  organizational  structure,  as  well  as  program  and  engineering 
planning  (SEP  plus  detailed  ESOH  planning  (HMMP/S SMP/S S PP)) . 

The  Environmental  Engineer  develops  and  implements  the  environmental  engineering  program  planning  to 
achieve  Program  Office  environmental  engineering  objectives  and  requirements.  The  planning  defines  the 
ESOH  tasks  and  functions  to  be  performed  and  products  to  be  developed:  timing  of  tasks,  task  outputs, 
resources  (skills,  tools,  equipment,  and  completion  criteria).  The  Environmental  Engineer  plans  tasks  to 
integrate  ESOH  activities  witliin  the  Program  Office,  between  Contractors  and  stakeholders.  The 
Environmental  Engineer  plans  the  tasks  to  establish  and  manage  hazards;  conduct  hazards  review  forums: 
support  SE&I  activities,  risk  management,  integration,  and  system  modifications:  coordinate  the  ESOH 
planning  with  SMC  Staff  Environmental  Engineering  office,  integrate  environmental  engineering  planning 
with  other  functional  and  acquisition  plans  (i.e.  SSMP,  SEP,  ASP,  LCMP). 

Execution  of  the  Environmental  Engineer  planning  is  typically  defined  tlirough  an  Operating  Instruction  which 
implements  SMC  and  liigher  level  instructions,  policies,  and  directives.  The  Environmental  Engineer  provides 
hill  support  to  define  the  program  and  technical  objectives  where  ESOH  challenges  and  risks  are  known  or 
anticipated.  The  Environmental  Engineer  assists  to  establish  the  business  model,  develop  program  planning 
and  schedules,  and  define  and  implement  program  processes.  The  Enviroiunental  Engineer  ensures  the  ESOH 
components  of  the  program  are  appropriately  represented  in  the  program  plans,  program  schedules,  work 
breakdown  schedules,  cost  estimates.  The  Environmental  Engineer  also  reports  their  technical  performance  and 
progress.  The  Environmental  Engineer  shares  in  the  risk  management  responsibilities  to  identify,  assess,  and 
propose  mitigating  actions  of  ESOH  related  risks.  They  also  support  the  program  manager's  problem 
identification,  resolution,  and  decision-making  processes. 


P&D  /  O&S  Phase  -  Technical  Products  Required 


SMC  ESOH  Technical 

Products 

ESOH  Contributions  to 
Other  Organizations * 
Products 

Inputs  tech  baseline  engineering 
changes 

Suppo  liability  assessment  Rpt 
Contribution 

Analyses  of  failures  and  mishap 
incidents 

Operational  Assessments 

Contributions 

Hazards  analyses  Report. 

Transition  &  Fielding  Docs 

PESHE  Update 

T&E  /  Demo,  ESOH  Reports 

ESOH  evaluations  of  Tech 
Orders,  operations  manuals 
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The  Environmental  Engineer  contributes  to  the  development 
of  the  program  management  products  identified  in  the  Table. 
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SMC  Program  Management  Products 


PMD 


SEP,  IMP  IMS  WBS 


Decision-making  &  problem  solving  inputs 


Technical  progression  and  issues  reporting 


LC  Cost  Estimate  (CARDs) 


Processes  (Qls) 


Risk  Management  Inputs 


PHM 
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Appendix  U  -  Prognosis,  Diagnostics  (Prognostics)  &  Health 
Management  (PHM)  Engineering 

Since  the  1960s.  most  electronic  military 
equipment  associated  with  space  and  airborne 
systems  has  been  developed  with  built-in-test 
(BIT)  capability.  BIT  capability  typically 
provides: 

•  Fault  detection 

•  System  (or  equipment)  response  to  the 
fault 

•  Fault  event  warning  anchor  logging  to 
aid  in  trouble  shooting 


More  sophisticated  BIT  designs  can  be 
characterized  as  passive  fault  diagnostics  and 
management  intended  mostly  for  airborne 
systems  to  support  the  maintenance  process.  For 
our  launch,  space  and  missile  systems,  unique 
constraints  (remote  systems,  minimal  event 
response  time,  autonomous  safety,  harsh 
environments)  drive  the  need  for  more 
sophisticated  and  autonomous  PHM.  Hence,  our 
space  systems  now  demand  active  fault 
management  system  designs  to  provide 
automated  and  high  fidelity  prognostics  of 
system  hardware  and  software  and  can  take 
proactive  measures  to  collect  faults 
autonomously.  The  table  below  summarizes 
common  PHM  capabilities  that  are  designed  into 
our  space,  launch,  and  missile  systems. 

Developing  and  designing  PHM  sub-systems  follows  the  engineering  requirements,  and  practices  summarized 
in  SMC  -S-Q01,  SMC-G-001,  and  the  SMC  Systems  Engineering  Handbook.  In  summary,  the  PHM  sub¬ 
system  is  fust  conceptualized  and  architected  based  on  the  required  operational  and  sustainment  capabilities 
and  established  constraints.  The  PHM  subsystem  design  is  then  increasingly  characterized  based  on  system  and 
allocated  requirements,  technical  solutions  trades  results,  and  top-down  (e.g.,  fault  tree)  and  bottom-up  (failure 
modes)  failure  analyses. 

To  be  specific,  as  the  system  design  is  engineered,  failure  precursors,  wfiicli  indicate  changes  in  a  measured 
variable  that  can  be  associated  with  impending  failure,  are  systematically  identified.  An  active  PHM  design 
solution  includes  automated  monitoring  of  the  failure  precursors,  prognostics,  and  fault  correction. 


System  Typical  PHM  Capabilities 


Spacecraft 

Spacecraft  PHM  capabilities  include  autonomous 
health  and  operations  monitoring  and  control;  power 
and  attitude  control  monitoring  with  automated 
systems  reset  and  restart;  transmitter  and  receiver  and 
communication  link  tests  automatic  reset  features  to 
restart  remote  computers. 

Launch 

Systems 

Pre-launch  failure  detection,  notification,  and  response 
for  abort  determination;  command  destruct  /self- 
destruct;  stage  event  monitoring  and  diagnostics; 
communication  systems  link  tests 

Missile 

systems 

Pre-launch  failure  detection,  notification,  and  response 
for  abort  determination;  command  destruct  /self- 
destruct,  stage  event  monltonng  and  diagnostics. 
Minuteman  Missile  was  one  of  the  first  major  weapons 
systems  designed  and  fielded  with  computer- 
controlled  BIT  systems 

Safety- 

critical 

devices 

Safety  devices  self-test  to  assure  their  continued 
operations.  Normally  there  are  two  tests.  A  power-on 
self-test  to  perform  device  diagnostics.  Then  periodic 
tests  to  assure  that  device  have  not  become  unsafe 
since  the  power-on  self-test. 

Computers  & 

Application 

Software 

The  typical  personal  computer  tests  itself  at  start-up 
with  the  BIOS  power-on  self-test  Most  computers, 
including  embedded  systems,  have  self-tests  of  the 
processor(s),  memory  and  application  software. 

Integrated 

Circuits 

In  integrated  circuits,  BIT  is  used  to  make  faster,  less- 
expensive  manufacturing  tests. 

Other 

Components 

Prognostics  are  designed  into  insulated  gate  bipolar 
transistor  (IGBT),  embedded  capacitors,  FPGAs, 
resettable  fuses,  to  name  a  few 
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PHM  provides  the  capability  to  make  intelligent,  informed,  and  appropriate  decisions  relating  to  system  faults 
within  and  across  systems  during  system  development,  integration  &  test,  and  operations  &  sustainment.  A 
solid  PHM  progr  am  will  also  provide  cost  savings  over  the  system  life-cycle. 

Key  attributes  of  PHM  include  real  time  or  near  real  time  health  status  availability;  proactive  advisory 
generation  based  on  health  state;  autonomic  logistics  (reduced  human  interaction):  no  or  minimal  false  alarms; 
and  autonomous  fault  management  to  preclude  safety  mishaps,  performance  degradation,  and  catastropliic 
failures.  The  SMC  Program  Office  designated  PHM  Engineer  will  likely  be  responsible  to: 

•  Lead  or  facilitate  the  conceptualization  and  arcliitectural  development  of  the  PHM  sub -system  and 
elements 

•  Ensure  adequacy  of  the  system  requirements  analyses  and  allocations  of  the  required  PHM  related 
capabilities. 

•  Support  technical  solutions  trades  and  supporting  PHM  analyses  for  optimal  and  cost  effective 
solutions. 

•  Ensure  implementation  of  the  PHM  requirements  and  identify  and  remedy  common  gaps  and  barriers 
to  acliieving  PHM 

•  Ensure  establishment,  implementation,  and  V&V  of  the  PHM  design  baseline 

The  PHM  Engineer  plans  and  executes  the  essential  PHM  engineering  and  management  efforts  in  an  integrated 
and  effective  manner  to  ensure  that  PHM  contribution  is  timely,  adequate,  consistent  and  compliant.  The  PHM 
Engineer  ensures  that  then  contributions  are  channeled  through  the  Systems  Engineering  Analyses  and  Control 
activity. 

Applicable  governance,  standards,  and  guidance 

Policy,  directives,  and  instructions  that  mandate  SMC  PHM  engineering  related  program  requirements  are 
included  hi  a  wide  range  of  mandates  including  those  providing  requirements  for  acquisition,  systems 
engineering,  reliability,  maintainability,  T&E,  system  safety,  and  others. 

DoD  Instruction  5000.02  directs  the  effective  sustainment  of  systems  resulting  from  the  design  and 
development  of  reliable  and  maintainable  systems.  The  operational  readiness  is  optimized  via  'diagnostics, 
prognostics,  and  health  management  techniques  in  embedded  and  off-equipment  applications  when  feasible 
and  cost-effective1'. 

DOD  Instruction  4151.22  instincts  the  application  and  integration  of  appropriate  processes,  technologies,  and 
knowledge  based  capabilities  through  Condition  Based  Maintenance  (CBM)  to  improve  the  reliability  and 
maintenance  effectiveness  of  DoD  systems  and  components.  Hie  CBM  strategy  includes  implementing  an 
optimum  mix  of  maintenance  technologies  (e.g.,  diagnostics  and  prognostics)  along  with  low  ambiguity  fault 
detection,  isolation  and  prediction. 

The  standards  provide  requirements  and  guidelines  for  conducting  research,  development,  and  implementation 
of  PHM  technology  and  PHM  design.  PHM  design  standards  are  often  specific  to  the  technology,  Line- 
Replaceable  Unit  (LRU)  type,  software  application  type,  and  device.  Hence,  they  are  largely  determined 
during  the  system  development  and  design  process. 


PHM  SMC  Spec  fa  /  A  Engi  i  /  eerf ?/g  DiscipJ  i  ties  261 

Table  26  Govern  a  ace,  standards,  and  guidance  that  shape  tUe  Prognostics  Health  Management  discipline 


Document  No 

Governance  Title 

Issue 

DOD  Instruction  5000.02 

Operation  of  the  Defense  Acquisition  System 

08  Dec  08 

DODI  4151.22 

Condition  Based  Maintenance  Plus  (GBM+)  for  Materiel  Maintenance 

02  Dec  07 

AFI 63-1201 

Life  Cycle  Systems  Engineering 

23  Jui  07 

AF1 10-602 

Determining  Mission  Capability  And  Sup  portability  Requirements 

18  Mar  05 

Document  No 

Standards  Title 

Issue 

SAE  JA1012 

A  Guide  to  the  Reliability-Centered  Maintenance  (RCM)  Standard 

01  Jan  02 

MIL-STD-810G 

DoD  Test  Method  Standard:  Environmental  Engineering  Considerations 
And  Laboratory  Tests 

31  Oct  08 

MIL-STD-883H 

DoD  Test  Method  Standard;  Microcircuits 

26  Feb  10 

IEEE  1149.1 

Standard  Test  Access  Port  and  Boundary-Scan  Architecture 

Jan  01 

IEEE-1149.4 

Mixed-Signal  Test  Bus 

Apr  99 

IEEE-1149.6 

Boundary-Scan  Testing  of  Advanced  Digital  Networks 

Jun  03 

Document  No 

Guidance  Title 

Issue 

IEEE  1149.1  Primer 

(JTAG)  Testability  Primer 

OSC  LCSP  Template 

25  Jul  09 

DoD  Guide  For  Achieving  Reliability,  Availability,  And  Maintainability 

03  Aug  05 

IEEE  1232-1995 

IEEE  Standard  for  Artificial  Intelligence  and  Expert  System  Tie  to 
Automatic  Test  Equipment  (Al -ESTATE):  Overview  and  Architecture 

21  Sep  95 

PHM  Engineers’  Contributions  to  tbe  Acquisition  Life  Cycle  Framework 

Tlie  E>oD  acquisition  life  cycle  is  defined  by  DoDI  5000.02,  The  PHM  Engineer  contributions  over  tins  life 
cycle  are  best  represented  within  the  phase  of  acquisition.  Figure  27  provides  the  acquisition  life  cycle 
framework  within  which  PHM  Engineers  perform  as  well  as  the  products  that  the  PHM  Engineers  must 
develop  or  contribute  to  their  development.  Tlie  SMC  Program  Office  PHM  Engineer  establishes  and 
implements  PHM  program  strategies  and  objectives  consistent  with  tlie  tenets  of  appropriate  policies.  SMC 
acquisition  objectives,  and  program  objectives.  The  Program  Office  PHM  Engineer  then  develops,  attains 
approval  for,  and  implements  PHM  pi  aiming  into  the  Systems  Engineering  Plan  (SEP)  and  higher  level 
integrated  pi  aiming  (e.g.,  IMP)  in  accordance  with  current  DoD  policy.  Tins  planning  is  firmly  based  on 
program  and  technical  objectives,  strategies,  DoD  mandates,  and  instructions. 

An  effective  PHM  program  supports  all  of  the  major  acquisition  activities  through  the  frill  system  life  cycle. 
Tlie  planning  sufficiently  defines  the  PHM  program  to  achieve  the  PHM  and  overall  program  objectives/goals 
and  requirements;  specifies  tasks  and  functions  to  be  performed,  timing  of  tasks,  resources  required,  products 
to  be  developed,  and  forms  the  basis  for  the  development  of  the  program  PHM  Operating  Instruction  (OI).  The 
PHM  planning  and  OI  are  then  reflected  appropriately  in  the  WBS,  IMS,  and  other  program  documents  that 
address  PHM  related  elements.  The  PHM  planning  is  executed  concurrently  with  tlie  Program  Office  OI  that 
documents  the  process  to  perform,  control,  and  integrate  all  PHM  engineering  and  management  activities  for 
each  phase  of  acquisition.  The  SMC  Program  Office  PHM  planning  (usually  contained  in  the  SEP  and  the 
detailed  PHM  program  planning)  and  OI  are  to  be  based  upon  the  appropriate  program-approved  life  cycle. 
SMC  Program  Offices  establish  and  implement  PHM  program  strategies  and  objectives  consistent  with  the 
tenets  of  appropriate  policies,  SMC  acquisition  objectives,  and  program  objectives. 
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1 .  Mat  eriel  Solution  Analysis.  Dm  mg  tills  phase  the  PHM 
Engineer  provides  inputs  to  and  supports  program 
acquisition  activities  to  include  the  development  of  the 
acquisition,  technology  demonstration,  test  strategies, 
inputs  to  the  cost  estimates,  solicitation/RPP  dev  elopment 
for  Contractor  studies,  and  proposal  evaluation  activities. 

The  PHM  Engineer  also  contributes  to  the  development 
of  the  MSA  Phase  acquisition  products. 


MSA  Phase  -  SMC  Acquisition  Pr o ducts 


ASP,  TDS;  DMS,  TES _ 

LC  Cost  Estimate _ 

APB,  CCA  Inputs;  Stated  Goals  for  PHM  tempered  with 
Affordability _ 

SSP  PHM  Goals  for  System  &  Subsystem  level _ 

SEP,  LCMPr  LCSP  Inputs,  Early  Concept  Development 
Inputs,  Cost  &  Schedule  Inputs 


2.  Techno  logy  Development.  The  PHM  Engineer  provides 
inputs  to  and  supports  program  acquisition  activities  to 
include  the  development  of  the  acquisition  strategy, 
updates  to  the  cost  model  and  dev  elopment  of  the  Cost 
Analysis  Requirements  Description  (CARD), 
solicitation/REP  development  and  proposal  evaluation 
activities. 


APB:  PHM  objectives  &  related  concept  descriptions 


The  PHM  Engineer  supports  the  development  of  the 
acquisition,  technology  demonstration,  and  test  strategies 
to  ensure  successful  implementation  of  PHM  capabilities. 

PHM  strategies  are  likely  integral  to  the  Reliability 
Av  ailability  Mainta inability  (RAM),  and  test  strategies  as  well  as  strategies  to  achieve  autonomous  system 
performance 


TD  Phase  -  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS,  TES 


LC  Cost  Estimate  Update  /  CARD  Development 


PHM  Operational  &  System  Requirements;  PHM 
Analyses  Requirements;  Data  Requirements  for  PHM 
Design,  Specialty  Tools  &  Skill  Sets  Required 


RFP:  PHM  objectives  in  the  S00;  PHM  related  tasks 
in  PWSp  PHM  data  products  in  CDRLs;  SMC-  PHM 
standards  -  tailored 


SSP:  evaluation  criteria  for  PHM 


Detailed  PHM  planning,  SEP,  LCMP,  LCSP,  TEMP, 
Concept  Development  Inputs,  PHM  Technologies, 
Cost  &  Schedule  Inputs 


The  PHM  Engineer  supports  the  definition  of  contract  requirements  such  as  PHM  performance  work 
statements  and  specification  requirements  associated  with  application  software  performance,  dev  elopment, 
and  qualification  to  meet  the  system  or  enterprise  lev  el  PHM  requirements  and  capabilities. 


The  PHM  Engineer  also  supports  the  definition  of  incentives  programs  as  well  as  PHM  related 
requirements  for  TScE,  reliability,  and  maintainability.  The  PHM  Engineer  contributes  to  the  development 
and  updates  to  the  TD  Phase  acquisition  products. 

3.  Engineering  &  Manufacturing  Development.  The 

PHM  Engineer  provides  inputs  to  and  supports  program 
acquisition  activities  to  include  updates  to  the  acquisition 
strategy  and  updates  to  the  cost  model  to  reflect  the  actual 
technical  solutions  determined  and  updates  to  the  CARD. 

The  PHM  Engineer  supports  the  development  of  the 
acquisition,  teclinology  demonstration,  and  test  strategies 
to  ensure,  successful  implementation  of  PHM  capabilities.  PHM  strategies  are  likely  integral  to  the  RAM, 
aud  test  strategies  as  well  as  strategies  to  achieve  autonomous  system  performance.  The  strategies  now 
extend  to  implementation  of  PHM  design  constraints  determined  through  system  trades  aud  engineering 
analyses. 


EMD  Phase  -  SMC  Acquisition  Products 


Updates  to  ASP,  TPS,  DMS,  TES _ 

CARD  update _ 

REP  PHM  objectives  in  tine  S00:  PHM  related  tasks 
in  SOW,  PHM  data  products  in  CDRLs  SMC-  PHM 
standards  -  tailored _ 

SSP:  evaluation  criteria  for  PHM _ 

APB:  PHM  objectives  &  related  concept  descriptions 
Detailed  PHM  planning,  SEP,  LCMP,  TEMP  updates 
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The  PHM  Engiiieer  supports  the  definition  of  contract  requirements  such  as  PHM  performance  work 
statements  and  specification  requirements,  and  detailed  design  specification  requirements  associated  with 
application  software  performance,  development,  and  qualification  to  meet  the  system  or  enteiprise  level 
PHM  requirements  and  capabilities. 

The  PHM  Engineer  supports  the  REP  development  and  proposal  evaluation  activities  which  include 
providing  the  technical  inputs  including  technical  requirements,  compliance  standards,  engineering 
approaches,  and  incentives  programs  to  meet  program  objectives. 

The  PHM  Engineer  also  supports  the  definition  of  incentives  programs.  T&E.  RAM  requirements.  The 
PHM  Engineer  also  contributes  to  the  updates  to  the  TD  Phase  acquisition  products. 

4.  Production  &  Deployment,  Operations  &  Support* 

The  PHM  Engineer  provides  inputs  to  and  supports 
program  acquisition  activities  to  include  updates  to  the 
acquisition  strategy  and  updates  to  the  cost  model  to 
reflect  the  actual  te clinical  solutions  determined  and 
updates  to  the  CARD.  The  PHM  Engineer  supports  the 
solicitation/RFP  development  and  proposal  evaluation 
activities.  The  PHM  Engineer  identifies  other  contract 
requirements:  incentives  programs:  production  and  field 
test  &  demo  requirements;  and  field  performance  and  sustainment  analyses  to  meet  PHM  objectives.  The 
PHM  Engineer  ensures  successfiil  validation  of  the  intended  prognostics,  diagnostics,  and  fault 
management  capabilities  through  operational  test  and  demonstration. 


Prodnce/O&S  -  SMC  Acquisition 
Products 


Updates  to  ASP,  TPS,  DM5,  TES _ 

RFP:  PHM  objectives  in  the  S00;  PHM  related  tasks 
in  SOW,  PHM  data  products  in  CDRLs;  SMC-  PHM 
standards  -  tailored _ 

SSP:  evaluation  criteria  for  PHM _ 

Detailed  PHM  planning,  SEP,  LCMP,  LCSP,  Test 
Planning  Updates  _ 

CARD  update 
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PHM  Engineers1  Contributions  to  the  Engineering  Life  Cycle  Framework 

Relationship  to  the  SE  Organization 

The  PHM  Engineer  plans  and  executes  essential  PHM  engineering  efforts  in  an  integrated  and  effective 
manner  within  the  context  and  full  support  of  the  overarcliing  Systems  Engineering  fiinction.  The  PHM 
Engineer  ensures  that  each  PHM  SED  contribution  is  timely,  adequate,  consistent,  and  compliant.  The  PHM 
Engineer  ensures  that  then  contributions  are  channeled  through  the  Systems  Engineering  Analyses  and  Control 
activity.  Systems  Engineers  manage  the  engineering  process  and  activities  depicted  in  Figure  3  while  the  PHM 
Engineer  contributes  to  this  process.  The  PHM  Engineer  supports  concept  &  architecture  development  and 
analyses;  modeling  and  simulation  efforts;  and  technology  studies.  The  PHM  Engineer  develops/derives  their 
requirements  and  supports  the  requirements  analyses  aud  allocations  process  They  also  participate  in  technical 
studies  and  solutions  trades  when  system  availability,  reliability,  maintainability,  survivability,  system  safety 
are  a  factor,  minimizing  unscheduled  maintenance,  extending  maintenance  cycles,  and  maintaining 
effectiveness  tlirougli  timely  repair  actions:  reducing  the  life-cycle  cost  of  equipment  by  decreasing  inspection 
costs,  downtime,  and  inventory;  and  improving  qualification  and  assisting  in  the  design  and  logistical  support 
of  fielded  and  future  systems. 

The  PHM  Engineer  also  works  closely  with  the  System  Engineers  to  ensure  PHM  hardware  &  software 
architectural  and  design  solutions  are  adequately  represented  in  the  system  architecture.  The  PHM  Engineer 
supports  the  System  Engineers 1  requirements  development  activities  to  define  requirements  for  development 
and  design  of  the  PHM  related  hardware,  software,  information  exchange  formats,  integrity  analyses,  etc.  The 
PHM  Engineer  aligns  closely  with  the  Rehab ilify  Engineer  to  perform  failure  analyses  to  determine  failure 
precursors,  define  prognostics  methods,  and  fault  collection  techniques. 

In  performing  the  management  and  control  function,  the  PHM  Engineer  ensures  their  teclmical  information 
advances  and  is  appropriately  applied  through  systematic  control,  collaboration  and  sharing  across  the 
organization.  For  example,  their-  analytical  products  (e.g.,  determinations  of  passive  verses  active  fault 
management  solutions)  must  be  timely  fed  back  to  the  architectural  development  team,  test  team,  and 
requirements  team  to  perform  their  unique  contributions,  and  must  be  provided  to  technical  and  program 
management  for  decision  making. 

Relationship  to  Other  SEDs 

The  PHM  Engineer  ensures  their  technical  contribution  to  the  overall  engineering  advances  and  is 
appropriately  applied  through  systematic  control,  collaboration  and  sharing  across  the  organization.  PHM 
Engineers  products  are  timed  and  applied  by  the  other  Specialty  Engineers  to  perform  their  unique 
contributions,  and  must  be  provided  to  teclmical  and  pro  .gram  management  for  decision  making. 

The  PHM  Engineer  works  closely  with  the  Logistics  Engineers  to  determine  maintenance  and  maintainability 
requirements  and  technical  solutions.  Implementation  of  the  PHM  related  requirements  are  initially  conveyed 
in  the  maintenance  concept  and  system  architecture.  The  PHM  Engineer  collaborates  with  the  Systems 
Engineer,  Architecture  Engineer,  T&E  Engineer,  and  Design  Engineer  to  ensure  the  system  architecture 
includes  PHM  related  technology,  physical  and  functional  solutions  that  implement  the  maintainability 
requirements  for  built-in  test  and  fault  management  requirements  for  real-time  or  periodic  system  integrity 
prognostics,  health  and/or  fault  reporting,  and  fault  collections  (autonomous  or  man-in-the-loop) . 
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The  PHM  Engineer  supports  the  Reliability  Engineer  in  the  performance  of  the  failure  analyses  to  identify 
failure  precursors  and  assist  to  determine  design  reliability  solutions  that  may  be  partially  achieved  through 
application  of  PHM  technologies,  devices,  and  techniques.  The  PHM  Engineer  supports  the  T&E  Engineer  to 
determine  alternative  and  cost  effective  test  solutions  that  are  balanced  to  also  meet  performance  requirements 
and  logistics,  reliability,  maintainability  and  other  constraints. 

The  PHM  Engineer  supports  the  System  Safety  Engineer  to  identify  requirements.  viable  technologies,  and 
design  solutions  for  safety  systems  and  devices  incorporating  PHM  such  as  safe  and  arm  systems  and 
command  destruct  devices. 

Tools  Selection  and  Use 

The  PHM  Engineer  considers  effectiveness  and 
efficiencies  gained  by  selecting  and  using  the  best 
choice  of  PHM  tools  considering  the  PHM  tool  needs 
for  fault  data  collection,  analyses,  reporting,  and  fault 
management. 

Engineering  Activities  and  Products  over  the  Life  Cycle 

The  following  subsections  delineate  PHM  contributions  to  engineering  activities  and  technical  products  by 
DOD  acquisition  phase.  The  Program  Office  determines  the  hill  scope  of  PHM  activities  and  products  that  are 
to  prepared  by  the  Program  Office  and  their  Contractors. 

There  are  many  aspects  of  the  prognostics  and  health  management  that  need  to  be  addressed  before  successful 
implementation  hi  any  system.  These  include  conceptualization  and  architectural  development  of  the  PHM 
subsystem  or  PHM  elements:  PHM  requirements  development:  technology,  architecture,  and  design  solutions 
trades:  and  verification  and  validation  of  PHM  specification  requirements  and  required  capabilities. 

Built-in  test  of  space  system  elements  provides  fault  finding  as  a  means  to  aid  in  system  unit  monitoring  and 
diagnostics.  BIT  status  is  beneficial  when  failure  occurrences  can  be  rapidly  isolated  to  a  particular  unit  and 
equally  usefiil  when  situations  result  in  no-fault  found  and  may  be  attributable  to  other  conditions.  The  unit 
BIT  provides  the  necessary  BIT  sensors  and  parametric  test  data  from  parametric  sensors,  to  the  system  level 
PHM  (application  software)  manager  for  diagnosing  the  root  cause  of  failure  aud  failure  predictions 
(Prognostics). 

In  summary,  effective  PHM  for  a  space  system  integrates  unit,  subsystem,  aud  system  level  prognostics,  health 
monitoring,  and  management  strategies;  consisting  of  diagnostic  and  prognostic  technologies,  with  an 
integrated  modeling  architecture  that  addresses  anomaly/failure  mitigation  to  optimize  performance  and  reduce 
life  cycle  costs. 

A  PHM  system  is  capable  of  comprehensive  failure  mode  diagnostic  and  prognostic  approaches  ranging  from 
generic  signal  processing  and  experience-based  algorithms  to  the  more  complex  knowledge  and  model-based 
techniques.  Prognostic  approaches  that  apply  to  space  systems  also  include: 

•  Reliability  and  Usage  Based  Prognostics 

•  Evoiutionaiy- based  Prognostics 

•  Data-Driven  Prognostic  Modeling 


Typical  PHM  Functions  Requiring  Tools 


PHM  Modeling  and  Architecture  Development 

PHM  Requirements  Analyses  &  Allocations 

Fault  Data  Collection  and  Reporting _ 

Prognostics  and  Health  Management  Analysis 
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•  P  ara  meter  E  stimation  B  as  ed  Approach 

•  Physics-Based  Approaches 


A  sample  depiction  of  how  tliis  may  be  implemented  is  illustrated  by  Figure  28  below. 


Mission  and  Command  Decisions  -  operations,  availability,  maintenance 


System  L?vei  PHM  Manager 


Analyze  Failure  Propagation  &  Interactions 


System  Rea  sorter  -  System  PHM  Model 


Anomaly  Detection,  Diagnostics,  Prognostics  S.'W 

Anomaly  Detection,  Diagnostics,  Prognostics  S.'W 

Anomaly  Detection,  Diagnostics,  Prognostics  S/W 

Analyze  Failure  Propagation  &  Subsystem 
Interactions 

Analyze  Failure  Propagation  &  Subsystem 
Interactions 

Analyze  Failure  Propagation  &  Subsystem 
Interactions 

System  Segment  Reason  er 


Network  Management  Segment  Reasoner 


i 


TnomalJnSetectlonT 

Diagnostics, 
Prognostics  S/W 


aT^rffetectlo 


Tnomaty 

Diagnostics, 
Prognostics  S/W 


TT&C  Subsystem  ||  CSS  Subsystem 


Anomaly  Detection, 

Diagnostics 


Subsystem  A 


Tnl 


tectr 


ion. 


iomal 
Diagnostics, 
Prognostics  SAW 


Subsystem  B 


Anomaly  Detection 


sr 


Anomaly  Detection, 
Diagnostics 


Interop  Enhancements  I  Antenna  Subsystem 


1  [ 


Resource  Performance 
Reporting 


Subsystem  C 


Communication  Segment  Reasoner 


A 
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System  Intranet 


Figure  28  Conceptual  illustration  of  PHM  implementation  on  a  satellite  control  system 

Additional  Functions  of  a  PHM  Manager.  The  System  Level  PHM  Manager  conceptually  monitors  an  entire 
system  status  to  identify  hardware  and  software  problems  across  the  system.  In  addition,  the  System  Level 
PHM  Manager  provides  tools  for  filtering  and  correlating  fault  information,  diagnosing  problems,  and 
resolving  these  problems  efficiently.  The  System  Level  PHM  Manager  may  opt  to  manage  hardware  and 
software  of  the  system  elements  if  they  are  not  managed  locally.  System  Level  PHM  Manager  performs 
configuration  management  of  all  elements,  services,  and  applications  hi  a  Services  Oriented  Architecture 
(SOA)  based  system.  Deployment  of  a  new  software  application  is  simply  a  deployment  of  a  software  package 
across  the  complete  SOA-based  system  network  for  user  consumption. 

For  launch  systems  recent  launch  failures  have  been  attributed  to  fairing  separation  issues  Examples  of  BIT 
technology  applied  to  launch  system  separation  devices  follow. 

Laser  or  Light  Emitting  Diode  Initiated  Ordnance.  Laser  or  built-in  light  emitting  diodes  are  used  to  supply 
the  initiation  energy.  These  devices  allow  the  simplification  of  factory  integration  and  checkout  due  to  its 
Built-in-Test  (BIT)  capability  to  verify  system  integrity  of  each  initiator. 

Intelligent  Initiation  System.  EBA&D  lias  developed  an  intelligent  electronic  initiation  system  (WizOrd®) 
based  on  a  semiconductor  bridge  initiator.  Employing  a  similar  safe  and  aim  architecture  as  laser  or  light 
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emitting  diode  initiated  ordnance,  this  intelligent  system  offers  real  time  BIT  and  health  monitoring  while  at 
the  same  time  operating  with  much  lower  draw  on  vehicle  power.  Both  attributes  provide  for  enhanced 
reliability  and  cost  for  the  overall  vehicle. 

Hence,  the  PHM  Engineer  ensures  PHM  considerations  during  early  concept  and  technology  development, 
identifies  plausible  solutions  to  system  PHM  methodologies  and  alternative  technologies  or  devices  for 
monitoring,  data  acquisition,  data  processing,  algoritlims  for  fault  identification,  fault  isolation,  failure 
prediction,  remaining  useful  life  estimation,  testing,  decision  making  for  condition  based  maintenance,  and 
fault  collection. 

1.  Materiel  Solution  Analysis*  During  tills 
phase  the  PHM  Engineer  may  provide  inputs 
to  and  support  program  acquisition  activities 
to  include  the  development  of  program 
acquisition  strategy,  input  to  the  cost 
estimates,  soiicitation/RFP  development  for 
Contractor  studies,  and  proposal  evaluation 
activities.  He  may  also  provide  input  to  the 
Capabilities  Based  Assessment  process  and  the  JCTDS  process.  The  PHM  Engineer  also  contributes  to  the 
development  of  the  MSA  Phase  technical  products. 

2.  Technology  Development*  During  tills 
phase  the  PHM  Engineer  continues  to 
provide  inputs  to  and  supports  the  JCIDS 
process.  The  PHM  Engineer  also  supports 
all  the  engineering  activities  highlighted 
within  the  box  titled  Engineering  Activities 
for  PHM  Development  &  Design  Figur  e  27 
to  commence  system  definition  and 
development.  PHM  Engineer  develops  and 
contributes  to  development  of  the  TD  Phase 
technical  products. 

The  PHM  Engineer  supports  the  concept, 
arcliitectural,  technology  development,  and 
engineering  trades  and  analyses  to  ensure  the 
concept,  architectural,  teclmology  and  design  solutions: 

•  Optimize  operational  readiness  through  affordable,  integrated,  embedded  diagnostics  and  prognostics. 

•  Enable  the  system  architectural  solutions  to  monitor  system  performance,  predict,  detect  isolate  and 
remedy  faults. 

•  Lead  toward  firm  support  ability  design  characteristics  that  in  the  system  and  design  specifications  for 
prognostics  &  diagnostics  capabilities/technologies  (including  built  in  test  and  health  state  reporting) 
supporting  condition  based  maintenance. 


TD  Phase  -  Technical  Products  Required 


SMC  Technical  Products 

PHM  Contributions  to 
Other  Organizations’ 
Products 

Inputs  to  ASP  TDS,  DMS,  TES 

Inputs  to  ASP 

System  Cost  Model,  LC  Cost 
Estimate /CARD 

Operational  Concepts 

RFP  Inputs:  S00;  PWS  Tasks, 
CDRLs,  DIDs;  PHM  system  & 
allocated  requirements 

AoA  Studies 

PHM  Factors  for  Studies/  Trades 

Operational  Assessments 

System  and  Service  DODAF 
Views;  ISP  inputs 

Input  to  SSP  &  evaluation  cnteria 
for  SSP ) 

Planning  Inputs:  SEP,  LCMP, 
LCSP,  Test  Plan  Si  Procedures 

Input  to  DoDAF  AVs,  CVs,  DiVsr 
OVs 

Inputs  to  R&M  failure  analyses; 
alternative  maintainability 

solutions,  BIT  analyses 

MSA  Phase  -  Technical  Products  Required 


SMC  PHM  Technical 

Products 

PHM  Contributions  to 
Other  Organizations5 
Products 

PHM  models;  inputs  to  concept, 
arch,  technology  studies  &  trades 

Operational  Concepts 

System  PHM  Req’ts  (draft) 

AoA  Studies 

PHM  nsk  assessments 

Initial  Capabilities  Doc  (ICD)  Dev 

Inputs  to  TDS,  DMS,  TES 

DoDAF  AVs,  CVs,  DIVs,  OVs, 

PHM 
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3.  Engineering  &  Manufacturing 
Development.  PHM  Engineer  continues  to 
provide  inputs  to  and  support  the  JCIDS 
process.  The  PHM  Engineer  supports  all  the 
engineering  activities  highlighted  within  the 
box  titled  Engineering  Activities  for 
Detailed  Design  Figure  27  to  commence 
detailed  systems  definition  and 
development. 

The  PHM  Engineer  establishes  collecting 
process,  whereby  lie  can  provide  DT&E 
inputs  arrived  at.  from  data  required  for 
Knowledge  Base  (KB)  development  and 
supports  the  JCIDS  process.  The  activities  of 
PHM  during  this  phase  are  extensive.  The 
PHM  Engineer  supports  the  solicits tion/RTP  development  and  proposal  evaluation  activities  which 
include  providing  the  technical  inputs  including  PHM  technical  requirements,  comp  fiance  standards  and 
engineering  approaches  to  meet  program  objectives.  PHM  Engineer  develops  and  contributes  to  the 
development  of  the  BMD  Phase  technical  products. 

The  PHM  Engineer  supports  the  LCMP  and  LCSP  implementation  to  ensure  the  technology  and  design 
solutions: 

*  Continue  to  optimize  operational  readiness  through  affordable,  integrated,  embedded  diagnostics  and 
prognostics. 

*  Effectively  monitor  system  performance,  predict,  detect,  so  late,  report,  and  remedy  faults  with 
minimal  false  alarms. 


EMD  Phase  -  Tech  meal  Products  Required 


SMC  PHM  Technical 

Products 

PHM  Connibutions  to 
Other  Organizations' 
Products 

Inputs  to  ASP  IDS,  DMS,  TES 

Inputs  to  ASP 

System  Cost  Model,  LC  Cost 
Estimate  /  CARD 

Operational  Concepts 

RFP  Inputs:  SCO,  PWS  Tasks, 
CDRLs,  DIDs;  PHM  system, 
allocated,  design  requirements 

AoA  Studies 

PHM  Factors  for  Studies/  Trades 

Operational  Assessments 

System  and  Service  DODAF 
Views;  TVs,  ISP  inputs 

Input  to  SSP  &  evaluation  criteria 
for  SSP} 

Planning  Inputs:  SEP,  LCMP, 
LCSP,  Test  Plan  &  Procedures 

Input  to  DoDAF  AVs,  CVs,  DIVs, 
OVs 

Assessments  of  tech  baseline 
engineering  changes 

Capabilities  Production  Doc 

Inputs  to  R&M  failure  analyses; 
maintainability  solutions,  BIT 

4. 


Production  &  Deployment,  Operations  & 
Support.  PHM  Engineer  continues  to 
provide  inputs  to  and  supports  the  JCIDS 
process.  The  PHM  Engineer  provides  input 
to  CAPD  as  part  of  Architecture  team  and 
supports  solicitation/RFP  development  and 
proposal  evaluation  activities.  The  PHM 
Engineer  contributes  to  the  development  of 
the  Produce  /  O&S  Phase  technical  products. 


Produce  /  O&S  Phase  -  Technical  Products  Required 

SMC  PHM  iecknieal 

Products 

PHM  Contributions  to 
Other  Organizations' 
Products 

CARD  inputs 

Sup  portability  Analyses  Rpt 

RFP  Inputs:  S00,  PWS  Tasks, 
CDRLs,  DIDs;  PHM  system, 
allocated,  design  requirements 

Operational  Assessments 

Assessments  of  tech  baseline 
engineering  changes 

Planning  Inputs:  SEP,  LCMP, 
LCSP;  Production  &  OT&E 
planning 

GIDEP  assessments;  Analyses  of 
reliability  &  test  reports 

PHM 
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PHM  Engineers1  Contributions  to  Program  and  Project  Management 

Each  SMC  program  defines  then  business  model  and  approach  structure  based  primarily  oil  their  program 
objectives,  program  and  technical  challenges,  organizational  structure,  as  well  as  program  and  engineering 
planning  (SEP,  LCSP,  LCMP  plus  detailed  PHM  planning). 

The  PHM  Engineer  develops  and  implements  the  PHM  program  planning  to  achieve  Program  Office 
objectives  and  requirements.  The  planning  defines  the  PHM  tasks  and  fiEietions  to  be  performed  and  products 
to  be  developed:  timing  of  tasks,  task  outputs,  resources  (skills,  tools,  equipment,  and  completion  criteria).  The 
PHM  Engineer  plans  tasks  to  integrate  PHM  activities  within  the  Program  Office,  between  Contractors  and 
stakeholders.  The  PHM  Engineer  plans  the  tasks  to  establish  and  manage  PHM  models,  requirements 
development,  failure  precursors  and  associated  teclmology  and  design  solutions:  support  SE&I  activities,  risk 
management,  integration,  and  system  modifications:  coordinate  the  PHM  planning  with  SMC/EN,  integrate 
PHM  engineering  plaiming  with  other  functional  and  acquisition  plans  (i.e.  SEP,  ASP,  LCMP,  LCSP). 

Execution  of  the  PHM  planning  is  typically  defined  through  an  Operating  Instruction  which  implements  SMC 
and  higher  level  instructions,  policies,  and  directives.  The  PHM  Engineer  provides  full  support  to  define  the 
program  and  technical  objectives  where  PHM  challenges  and  risks  are  known  or  anticipated.  The  PHM 
Engineer  assists  to  establish  the  business  model,  develop  program  planning  and  schedules,  and  define  and 
implement  program  processes.  The  PMP  Engineer  ensures  the  PHM  components  of  the  program  are 
appropriately  represented  in  the  program  plans,  program  schedules,  work  breakdown  schedules,  cost  estimates. 
The  PHM  Engineer  also  reports  their  technical  performance  and  progress.  The  PEIM  Engineer  shares  in  the  risk 
management  responsibilities  to  identify,  assess,  and  propose  mitigating  actions  of  PHM  related  risks.  They  also 
support  the  Program  Manager's  problem  identification, 
resolution,  and  decision-making  processes. 

The  PHM  Engineer  contributes  to  the  development  of  the 
program  management  products  identified  in  the  Table. 


SMC  Program  Management  Products 


PMP _ 

SEP,  IMP,  IMS,  WBS 

Decision-making  &  problem  solving  inputs 

Technical  progression  and  issues  reporting 

LC  Cost  Estimate  (CARDs) _ 

Processes  (OEs) _ 

Risk  Management  Inputs 
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Acronym  List 


Acronym 

Definition 

AME 

Arms,  Ammunition,  and  Explosives 

AGAT 

Acquisition  Category 

Advanced  Concept  Technology 

ACTDs 

Demonstrations 

ADM 

Acquisition  Decision  Memorandum 

AF 

Air  Force 

AFI 

Air  Force  Instruction 

AFISC 

Ar  Force  Inspection  and  Safety  Canter 

AFMAN 

Ar  Force  Manual 

AFOSH 

Ar  Force  Occupational  Safely  and  Health 
Ar  Force  Operational  Test  and 

AFOTEC 

Evaluation  Center 

AFPD 

Ar  Force  Policy  Directive 

AF3C 

Ar  Force  Space  Command 

AFSPC 

Ar  Force  Space  Command 

AFSPC! 

Ar  Force  Space  Command  Instruction 
Amen  can  institute  of  Aeronautics  and 

AIAA 

Astronautics 

Acquisition  Information  Assurance 

AIAS 

Strategy 

AIS 

Automated  Information  System 

ANS 

Amen  can  National  Standard 

AoA 

Analysis  of  Alternative 

AoA 

Analysis  of  Alternative 

APB 

Acquisition  Program  Baseline 

APB 

Acquisition  Program  Baseline 

Archs 

Architectures 

ASD 

Acquisition  Strategy  Document 

ASP 

Acquisition  Strategy  Panel 

Amen  can  Society  for  Testing  and 

A3TM 

Materials 

AT 

Anti-Tamper 

ATEA 

Anti-Tamper  Executive  Agent 

AV 

A!  View 

BIT 

Built-in-Test 

C&A 

Certification  and  Accreditation 

CAE 

Component  Acquisition  Executive 

CARD 

Cost  Analysis  Requirements  Description 

CBA 

Capabilities  Based  Assessment 

CBDP 

Chemical  and  Biological  Defense 

CBM 

Program 

Condition  Based  Maintenance 

CBRN 

Chemical,  Biological,  Radiological,  and 
Nuclear 

CCA 

CEinger-Cohen  Ad 

CCA  Cert 

Clinger-Cohen  Act  Certification 

CDD 

Capability  Development  Document 

CDR 

Critical  Design  Review 

CDRL 

Contract  Data  Requirements  Lists 

Cl 

Commercial  Items 

CIO 

Chief  information  Officer 

CISP 

Counterintelligence  Support  Plan 

CJCS 

Chairman  of  the  Joint  Chiefs  of  Staff 

CJCSI 

Chairman  of  the  Joint  Chiefs  of  Staff 
Instruction 

CJC3M 

Chairman  of  the  Joint  Chiefs  of  Staff 
Manual 

CL 

Confidentiality  Level 

CLIN 

Contract  Line  Item  Number 

CMM! 

Capability  Matunty  Model  Integration 

CNSSS 

Committee  on  National  Security  Systems 
Instruction 

COEA 

Cost  and  Operational  Effectiveness 
Analysis 

COI 

Critical  Operational  Issues 

COM 

Computer  Operation  Manual 

CONOPS 

Gen  cep  of  Operations 

COPVs 

Composite  Overlapped  Pressure 
Vessels 

COQ 

Cost  of  Quality 

COTS 

Commercial  Off  The  Shelf 

CPAT 

Critical  Process  Assessment  Tool 

CPD 

Capability  Produdion  Document 

CPI 

Critical  Program  Information 

CPM 

Computer  Programming  Manual 

CRD 

Capstone  Requirements  Document 

CRRA 

Capability  Requirements  and  Risk 
Assessments 

GSERIAC 

Crew  System  Ergonomics  Information 
Analysis  Center 

CSP 

Cryptography  Security  Plan 

CTEs 

Critical  Technology  Elements 
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cv 

Capability  Viewpoint 

and  Evaluation 

D&D 

Development  and  Demonstrate 

Dedrine,  Organization,  Training,  Materiel, 
Leadership  &  Education,  Personnel  or 

DM 

Designated  Accrediting  Authority 

DOTMLPF 

Facilities 

DAG 

Defense  Acquisition  Guidebook 

DPA 

Destructive  Physical  Analysis 

DASD 

Deputy  Assistant  Secretary  of  Defense 

DR 

Deficiency  Reporting 

DAU 

Defense  Acquisition  University 

Deficiency  Reporting  and  Investigating 

DBDD 

Database  Design  Description 

DRIS 

System 

DCID 

Director  of  Centra!  InteJIigence  Directive 

DT&E 

Developmental  Test  and  Evaluation 
Ensign-Bickford  Aerospace  and  Defense 

DCMA 

Defense  Contract  Management  Agency 

EBA&D 

Company 

Doctrine,  Organization,  Training,  Materiel, 

Engineering  Change  Proposal  System 

Leadership  k  Education,  Personnel  or 

ECPSSR 

Safety  Report 

DCR 

Facilities  (DOTMLPF)  Change 

Recommendation 

EIAP 

Environmental  Impact  Analysis  Process 

DDL 

Delegation  of  Disclosure  Authority 

El  As 

Environmental  Impad  Assessments 

USAF  Enterprise  Information  Technology 

DDMS 

DoD  Discovery  Metadata  Specification 

EIDTR 

Data  Repository 

Delta  PDR 

Delta  Preliminary  Design  Review 

EISP 

Enhanced  Information  Support  Plan 

DFARS 

Defense  Federal  Acquisition  Regulation 
Supplement 

Department  of  Defense  Information 

Assurance  Certification  and  Accreditation 

EM 

eMASS 

Electromagnetic 

Enterprise  Mission  Assurance  Support 
Service 

DIACAP 

Process 

EMC 

Electromagnetic  Compatibility 

Department  of  Defense  Information 

Electro  magnetic 

Assurance  Certification  and  Accreditation 

EMC/EMI 

Compati  bi  Si  ty/l  nte  rfe  rence 

DIACAP/Cert 

Process 

EMCE 

Electromagnetic  Compatibility  Engineer 

DID 

Date  Item  Description 

Engineering  and  Manufacturing 

DIP 

DIACAP  Implementation  Ran 

EMD 

Development 

DISA 

Defense  Information  Systems  Agency 

EME 

Electro  magnetic  Environment 

Defense  Information  Technology 

EMI 

Electromagnetic  Interference 

DISR 

Standards  Registry 

Electromagnetic  Interference  Control 

DIVs 

Data  and  Information  Viewpoint 

EMICP 

Procedures 

Eledro magnetic  Interference  Test 

DLA 

Defense  Logistics  Agency 

EMITP 

Procedures 

DMS 

Data  Management  Strategy 

EMITR 

Electromagnetic  Interference  Test  Report 

DMS 

Data  Management  Strategy 

EMP 

Eledro  magnetic  Pulse 

DMSMS 

Diminishing  Manufacturing  Sources  and 

Material  Shortages 

EMV 

Etedro magnetic  Vulnerability 

DoC 

DoD 

Department  of  Commerce 

Department  of  Defense 

EN 

EOLP 

SMC/Engineering 

End  of  Life  Plan 

Department  of  Defense  Architecture 

EP 

Eledronsc  Protection 

DoDAF 

Framework 

ESD 

Electrostatic  Discharge 

DoD  Architecture  Framework  Operational 

Environmental,  Safety,  and  Operational 

DoDAF  OVs 

Views 

ESOH 

Health 

DoDAF  OVs, 

Architecture  Framework  Operational 

SVs 

Views,  Service  Views 

FEM 

Finite  Element  Modeling 

Federal  Information  Processing 

DoDD 

Department  of  Defense  Directive 

FIPS 

Standards 

DoDI 

Department  of  Defense  Instruction 

FMEA 

Failure  Mode  and  Effects  Analysis 

DoDR 

Department  of  Defense  Regulations 

FOC 

Full  Operational  Capability 

DOT&E 

Office  of  the  Director,  Operational  Test 

FOM 

Figure  of  Merit 
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FRACAS 

Failure  Reporting  And  Corrective  Action 

System 

IEEE 

Institute  of  Electneal  and  Electronics 
Engineers 

FRB 

Failure  Review  Board 

ILS 

Integrated  Logistics  Support 

FSM 

Firmware  Support  Manual 

ILSP 

Integrated  Logistic  Support  Plan 

FTSR 

Flight  Termination  System  Report 

IMP 

Integrated  Master  Plan 

GFE 

Government  Furnished  Equipment 

IMS 

Integrated  Master  Schedule 

GIDEP 

Government-Industry  Data  Exchange 

Program 

IOC 

Initial  Operational  Capability 

GIG 

Global  information  Gnd 

Hardness  Assurance,  Maintenance,  and 

IOT&E 

IP 

Initial  Operational  Test  and  Evaluation 

Internet  Protocol 

HAMS 

Surveillance 

IPsec 

Internet  Protocol  Secunty 

HAND 

High  Altitude  Nuclear  Detonation 

IPT 

Integrated  Producl/P  recess  Team 

HARs 

Hardware  Acceptance  Reviews 

IPv6 

Internet  Protocol  version  6 

HAZMA1 

Hazardous  Materials 

IRS 

Interface  Requirements  Specification 

HDBK 

Handbook 

ISO 

Information  Systems  and  Organizations 

HE 

Human  Engineering 

International  Organization  for 

HEMP 

High-Altitude  Electromagnetic  Pulse 

ISO/I  EC 

Standardization/lntemational 
Electrotechnical  Commission 

HERF 

Hazards  of  Electromagnetic  Radiation  to 

Fuel 

ISP 

Information  Support  Plan 

HERO 

Hazards  of  Electromagnetic  Radiation  to 
Ordnance 

ISSE 

Information  Systems  Secunty 
Engineenng 

Hazards  of  Electromagnetic  Radiation  to 

IT 

Information  Technology 

HERP 

Personnel 

ITT 

Integrated  Test  Team 

HFE 

Human  Factors  Engineenng 

ITU 

International  Telecommunication  Union 

HHA 

Health  Hazard  Assessment 

IUID 

Item  Unique  Identification 

HHAR 

Health  Hazard  Assessment  Report 

Joint  Capabilities  Integration 

Hazardous  Materials  Management 

JOTS 

Development  System 

HMMP 

Program 

Joint  041  Program  Assessment  Tool  - 

HN 

Host  Nation 

JCPAT-E 

Empowered 

HSI 

Human  Systems  Integration 

JDM 

Joint  Depot  Maintenance 

HSIP 

Human  Systems  Integration  Plan 

JRMET 

Joint  Reliability  &  Maintainability 
Evaluation  Team 

HW 

Hardware 

JROC 

Joint  Requirements  Oversight  Council 

j&S 

Interoperability  and  Sop  portability 

KB 

Knowledge  Base 

l&S/NC 

Interoperability  and  Sopportability  /  Met 

Centric 

KPP 

Key  Performance  Parameters 

IA 

Information  Assurance 

KSA 

Key  System  Atlnbutes 

fAE 

Information  Assurance  Engineer 

LC 

Life  Cycle 

1AM 

Information  Assurance  Manager 

LC  Cost 
Estimate 

Life  Cyde  Cost  Estimate 

IAS 

Information  Assurance  Strategy 

LCC 

Life  Cyde  Cost 

IATT 

Interim  Authonty  to  Test 

LCMP 

Life  Cyde  Management  Plan 

IAW 

In  accordance  with 

LCSP 

Life-Cyde  Sustainment  Plan 

1C 

Initial  Capabilities 

LCSSP 

Life^Cyde  Signature  Support  Plan 

ICD 

Initial  Capabilities  Document 

LFT&E 

Live  Fire  Test  and  Evaluation 

ICW 

Interactive  Courseware 

LL 

Long  Lead 

IDD 

Interface  Design  Descnption 

LMI 

Logistics  Management  Information 

Acronym 

LRU  Line-Replaceable  Unit 

LSA  Logistics  Support  Analyst 

LSAR  Logistics  Support  Analyst  Report 

MAP  Manufacturing  and  Producibility 

MSS  Modeling  and  Simulation 

MAC  Mission  Assurance  Category 

MAIS  Major  Automated  Information  System 

Manpower  Training  Research  Information 
MATRIS  Systems 

Mil  i  lary  Commumca  lions-  E  lectro  nics 
MCEB  Board 

MDA  Milestone  Decision  Authority 

MDAPs  Mapr  Defense  Acquisition  Programs 

ME  Manufacturing  Engineers 

MER  Manpower  Estimate  Report 

MfgT  ech  Ma  nufacton  ng  T  echnology 

Mil-Std  Military  Standard 

MOAs  Memorandum  of  Agreements 

MOEs  Measures  of  Effectiveness 

MOPs  Measures  of  Performance 

M  OSs  Measu  res  of  Sui  tabi  lity 

MP  Manufacturing  and  Producibility 

MPCP  Mass  Properties  Control  Plan 

MRAR  Mishap  Risk  Assessment  Report 

MRB  Material  Review  Board 

MRRs  Manufactunng  Readiness  Reviews 

MS  Milestone 

MSA  Matenel  Solution  Analysis 

National  Air  and  Space  Intelligence 
NASIC  Center 

NC  Net  Centnc 

NCOS  Net-Centnc  Data  Slrategy 

NCE  Net  Centnc  Engmeenng 

NCES  Net-Centnc  Enterpnse  Services 

NCOW  Net  Centnc  Operation  Warfare 

NCW  Net-Centnc  warfare 

NDAA  National  Defense  Authorization  Ad 

NDIs  Non-Developmenlal  Items 

NEFA  National  Environmental  Policy  Act 

NEPA  EO  National  Environmental  Policy  Act 

121 14  Executive  Order 

Net-Centnc  Enterpnse  Solutions  for 
NESI  Interoperability 
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Network  Operations 
National  Industnal  Secunty  Program 
NISPOM  Operating  Manual 

National  institute  of  Standards  and 
NIST  Technology 

NR-KPPs  Net  Ready-Key  Performance  Parameters 

NS  A  Na  tonal  Security  Agency 

NSS  National  Secunty  Systems 

National  Telecommunications  and 
NTIA  Information  Administration 

OAM  Operations  and  Maintenance 

OAS  Operations  and  Support 

Occupational  Safety  and  Health 
OASHA  /^ministration 

OCD  Operational  Concept  Description 

OFS  Olher  Findings  of  Significance 

01  Operating  Instructions 

OMB  Office  of  Management  and  Budget 

OPR  Offiaaf  Person  Responsible 

OPSEC  DoD  Operations  Secunty 

ORD  Operational  Requirements  Document 

ORS  Other  Recommendations  of  Significance 

OS  Operations  and  Support 

OSD  Office  of  the  Secretary  of  Defense 

Operational  Safety,  Suitability  and 
GSSAE  Effectiveness 

OT  Opera  tonal  Test 

OT&E  Operational  T est  and  Evaluation 

OV  Operational  Viewpoints 

PAD  Production  and  Deployment 

Production  and  Deployment  /  Operations 
PAD/O&S  and  Support 

PC  A  Physical  Configuration  Audit 

PD  Directive 

PDR  Preliminary  Design  Review 

PEO  Program  Executive  Officer 

Programmatic  Environment,  Safety  and 
PESHE  Occupational  Health  (ESOH)  Evaluation 

Program  Environmental  Safety  Health 
PESHEWG  Evaluation  Working  Group 

PGI  Procedures,  Guidance,  and  Information 

PHAR  Preliminary  Hazard  Analysis  Report 

PHL  Preliminary  Hazard  List 

PHM  Prognostics  Health  Management 

Packaging,  Handling  Storage  and 
PHSAT  Transportation 
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Project  Management ,  Program 

Management,  Project  Manager,  or 

SCG 

Security  Classification  Guide 

PM 

Program  Manager 

SD 

Systems  Director 

PMD 

Program  Management  Directive 

S-D 

Spectrum-Dependent 

PMP 

Parts  Matenals  and  Processes 

SOAR 

Space  Debns  Assessment  Report 

PMP 

Program  Management  Plan 

SOD 

Software  Design  Description 

PMPCB 

Paris  Matenals  and  Processes  Control 

Board 

SDD 

SOP 

System  Design  Descnplion 

Parts  Matenals  arid  Processes  Selection 

Software  Development  Plan 

PMPSL 

List 

SDR 

System  Design  Review 

PMSDL 

Parle,  Matenals,  Selection  Data  List 

SE 

Systems  Engmeenng 

POA&M 

Plan  of  Action  and  Milestones 

SE&I 

Systems  Engmeenng  and  Integration 

POC 

Point  of  Contact 

SED 

Specially  Engmeenng  Disciplines 

PP 

Program  Protection 

SEP 

Systems  Engineenng  Plan 

PRAT 

Program  Protection  /  Anti -Tamper 

SHA 

Safety  Hazard  Analysis 

PPE 

Program  Protection  Engmeenng  / 

Program  Protection  Engineer 

SIB 

Safety  Investigation  Board 

PPP 

S1GINT 

Signals  Intelligence 

Program  Protection  Plan 

SIM 

PSM 

Product  Support  Manager 

Serialized  Item  Management 

PWS 

Performance  Worft  Slatement 

SIO 

Single  Investigator 

Seftware  Installation  Plan  or  System 

QA 

Quality  Assurance 

SIP 

Identification  Profile 

CWQE 

Quality  Assurance  and  Quality  Engineer 

SM 

Spectrum  Management 

QAE 

Quality  Assurance  Engmeenng 

SMC 

Space  And  Missile  Systems  Center 

QAOE 

Quality  Assurance  Officer/Engineer 

SMC/EN 

Space  And  Missile  Systems  Center  / 
Engineenng 

QAP 

Quality  Assurance  Program 

Space  And  Missile  Systems  Center 

QATech 

Quality  Assurance  Technical 

SMC! 

Instruction 

RAM 

Reliability  Availability  Maintainability 

SMD 

Standard  Microcircuit  Drawing 

RBD 

Reliability  Block  Diagram 

SME 

Subject  Matter  Expert 

RCM 

Reliability  Centered  Maintenance 

SOA 

Services  Oriented  Architecture 

RDT&E 

Research,  Development,  Test  And 

Evaluation 

SOH 

SOO 

Safety  and  Occupational  Health 

Reliability  And  Maintainability  Information 

Statement  of  Objectives 

REMIS 

System  Assessments 

SOW 

Statement  of  Work 

RE 

Radio  Frequency 

SPAWAR 

Space  and  Naval  Warfare  Systems 
Command 

REP 

Request  for  Proposal 

Specs 

Specifications 

RHOC 

Radi  a  lion  Hardened  Oversight  Council 

Spectrum 

RPP06 

Replenishment  Parts  Purchase  or  Borrow 

Sup  Cert 

Spectrum  Supportability  Certification 

RSSP 

Replaced  System  Sustainment  Ran 

SPICE 

Software  Process  Improvement 
Capability  Determination 

RTP 

Research  and  Technology  Protection 

SPO 

System  Program  Office 

S&T 

Science  And  Technology 

SPS 

Software  Product  Spocifi cation 

SAG 

Software  Acquisition  Guidebook 

SOA 

Software  Quality  Assurance 

SAR 

Safety  Assessment  Report 

SQE 

Software  Quality  Engineers 

SAWE 

Society  of  Allied  Weight  Engineers 

SRD 

Software  Requirements  Desoiption 

SCD 

Specification  Control  Drawings 

SRDR 

Software  Resources  Data  Report 
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SRR 

System  Requirements  Review 

SRS 

Software  Requirements  Specification 

ss 

Spectrum  Suppertability 

SSA 

Space  Situational  Awareness 

SSA 

Source  Selection  Authority 

SSDD 

System/Segment  Design  Description 

3SE 

System  Secunty  Engineering 

SSEB 

Source  Selection  Evaluation  Board 

SSG 

System  Safety  Group 

SSHA 

System  Safety  Hazard  Analysis 

SSHAR 

System  Safety  Hazard  Analysis  Report 

SSL 

Space  Survivability  Levels 

SSM 

System  Safety  Manager/Engineer 

System  Safely  Management  Plan  or 

SSMP 

System  Secunty  Management  Plan 

SSP 

Source  Selection  Plan 

SSPP 

System  Safety  Program  Plan 

SSPPR 

System  Safety  Program  Progress  Report 

SSRA 

Spectrum  Supporlability  Risk  Assessment 

SSS 

System/Segmenl  Specification 

SSWG 

System  Safety  Working  Group 

STA 

System  Threat  Assessment 

STAR 

System  Threat  Assessment  Report 

STD 

Software  Test  Description 

StdVs 

Standards  Viewpoints 

STIC 

Space  Technology  Integrator  Council 
Secunty  Technical  Implementation 

STIG 

Guides 

SIP 

Software  Test  Plan 

STR 

Software  Test  Reporf 

STrP 

Software  Transition  Plan 

SUM 

Software  User  Manual 

Systems  and  Services  Viewpoint  or 

SV 

Space  Vehicle 

SvcV 

Services  Viewpoint 

SVD 

Software  Version  Description 

Survivability  and  Vulnerability  Program 

SVPP 

Plan 

SW 

Software 

SWAMP 

Software  Acquisition  Management  Plan 

SysML 

Systems  Modeling  Language 

T&E 

Test  and  Evaluation 

TA/CP 

Technology  Assessment  and  Control 

Plan 

TAFIM 

Technical  Architecture  Framework  for 
Information  Management 

TBA 

to  be  addressed 

TBD 

to  be  developed,  or  to  be  determined 

TD 

Technology  Development 

TDS 

Technology  Development  Strategy 

TDSB 

Test  Data  Sconng  Board 

TEMP 

Test  and  Evaluation  Master  Plan 

TEO 

Technology  Executive  Officer 

TES 

Test  and  Evaluation  Strategy 

TISP 

Tailored  Information  Support  Plan 

TMCR 

Technical  Manual  Contract  Requirements 

TO 

Technical  Orders 

TOA 

Turnover  Agreement 

TOC 

Total  Ownership  Cost 

TPIPT 

Technical  Planning  Integrated  Product 
Team 

IRA 

Technology  Readiness  Assessment 

T  raceability 
Rqls 

Traceability  Requirements 

TRD 

Technical  Requirements  Document 

TRL 

Technical  Readiness  Level 

TRR 

Test  Readiness  Reviews 

TSP 

Transition  Support  Ran 

me 

Tracking,  Telemetry,  and  Command 

TVs 

Technical  Standards  View 

UML 

Unified  Modeling  Language 

US 

United  States 

USAF 

United  States  Air  Force 

use 

United  States  Code 

V&V 

Verification  and  Validation 

WBS 

Work  Breakdown  Structures 

WDSSR 

Waiver  or  Deviation  System  Safety 

Report 

WizOrd 

EBMC  developed  Intelligent  Electronic 
Initiation  System 
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